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There  Is  a need  tn  the  Air  Force  to  reduce  the  costs 
and  the  complexity  of  computer  program  development.  This 
can  be  done  by  making  the  development  efforts  more  visible 
to  management  and  by  demanding  that  more  effective  and 
reliable  engineering  practices  he  used.  This  study  supported 
both  these  objectives.  It  Identified  status  accounting  re- 
quirements for  software  configuration  management,  and  it 
adhered  to  current  software  engineering  disciplines  to  ob- 
tain a software  design  for  an  automated  status  accounting 
system. 

I cannot  overstate  the  importance  of  the  design  phase 
of  software  development.  Since  errors  In  design  are  not 
usually  discovered  until  late  In  the  software  development 
project,  correcting  them  often  requires  reworking  many  parts 
of  the  system.  This  contributes  both  to  project  delays  and 
to  cost-overruns.  The  design  presented  In  this  report  was 
obtained  using  methodologies  which,  I feel,  make  the  soft- 
ware more  understandable,  thus  reducing  the  potential  for 
error.  I recommend  that  they  be  used  In  other  software 
development  effprts. 

I wish  to  thank  Captain  Frank  E.  Douglas,  Mister  Robert 
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Abstract 


This  report  documents  a design  effort  for  an  automated 
system  to  record  and  report  the  configuration  status  of 
software  for  Air  Force  embedded  computer  systems.  The 
work  included  requirements  analysis,  software  design,  and 
database  design.  Because  of  the  flexibility  given  to  pro- 
gram managers  In  tailoring  their  reporting  requirements 
and  in  selecting  the  data  "Integator",  only  the  require- 
ments of  a single  AFSC  program  office  were  presented  In 
detail.  However,  the  requirements  of  other  offices  were 
considered  as  well.  Current  software  engineering  tech- 
niques were  used  to  derive  the  design.  They  are  highly 
recommended  for  use  on  other  software  development  projects. 
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Background 

The  Simulator  System  Program  Office  (SIMSPO)  of  the 
Aeronautical  Systems  Division  at  Wri ght-Patterson  AFB,  Ohio, 
sponsored  this  thesis.  The  SIMSPO  is  one  of  many  Air  Force 
organizations  tasked  with  acquiring  resources  in  accordance 
with  the  Air  Force  800  series,  "Acquisition  Management", 
regulations.  It  is  responsible  for  acquiring  flight  trainer 
simulators  for  12  different  types  of  aircraft.  Since  these 
simulators  will  be  controlled  by  embedded  computer  systems, 
the  SIMSPO's  activities  are  governed  by  Volumes  I and  II  of 
the  Air  Force  Regulation  ( A F R ) 800-14  (Refs  3,4).  These 
volumes  consolidate  and  explain  policies  and  procedures  that 
pertain  specifically  to  the  acquisition  management  of  computer 
resources . 

Acquisition  management  encompasses  several  highly  re- 
lated, yet  separately  identified,  management  disciplines, 
one  of  which  is  configuration  management.  Configuration 
management  consists  of  three  tasks:  identification,  control, 
and  status  accounting  of  items  being  acquired  (Refs  2,3). 
Although  status  accounting  is  the  subject  of  this  thesis, 
it  is  so  closely  tied  to  identification  and  control  that  all 
three  tasks  are  briefly  introduced  below. 

Configuration  identification  is  the  set  of  documents 
and  engineering  drawings  which  describes  a system  being 
acquired.  Hardware  and  software  which  will  be  delivered  to 
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the  procuring  activity  to  serye  end-use  functions  are  de- 
signated as  configuration  items  CCIsI  and  computer  program 
configuration  items  CCPCIsl,  respectively.  As  a Cl  or  CPCI 
design  evolves,  its  technical  description  (documentation) 
constitutes  its  configuration  identification  and  represents 
the  requirements  for  the  Cl  or  CPCI  to  be  developed.  When 
the  configuration  identification  for  an  item  is  "suffici- 
ently" defined  (that  is,  when  the  documentation  represents 
a meaningful  contractual  requirement),  it  is  "frozen". 

The  documentation  at  that  point  in  time  is  the  item's  base- 
line, subsequent  changes  to  which  are  formally  controlled. 

"Configuration  control  consists  of  the  formal  proce- 
dures by  which  changes  to  configuration  items  are  documented, 
processed,  and  authorized"  (Ref  34:53).  These  changes  are 
accomplished  in  response  to  engineering  change  proposals 
(ECRs):  documents  which  describe  proposed  alterations  to 
baselined  specifications.  Associated  with  an  ECP  is  a set 
'of  change  pages  for  eac-h  of  the  configuration  identification 
documents  that  the  ECP  affects.  Each  set  of  change  pages 
includes  a cover  sheet  called  a change  notice  (CN).  CNs 
enumerate  all  the  pages  within  the  document  that  have  been 
changed  since'  a'  revision  to  the  document  was  last  issued. 
Together,  an  item's  baseline  documents,  ECPs,  and  CNs  pro- 
vide a complete  history  of  the  development  and  maintenance 
of  the  item. 

The  third  task  of  configuration  management  is  status 
accounting.  Configuration  status  accounting  (CSA)  is  a 
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system  of  reports  and  records  that  provtdes  visibility  and 
traceability  of  configuration  baselines  and  the  changes  to 
those  baselines.  C$A  "identifies  an  item's  initial  approved 
configuration,  then  continuously  tracks  changes  proposed  to 
that  configuration,  as  well  as  the  priority,  schedule,  and 
progress  of  changes  that  are  approved"  (Ref  5:30).  It  is 
a tool  to  aid  configuration  managers  perform  tasks  related 
to  the  changes  being  made  to  an  item.  As  such,  a program's 
CSA  requirements  should  be  tailored  to  fit  the  program 
manager's  needs. 

Statement  of  the  Problem 

The  impetus  behind  this  thesis  is  the  need  for  a system 
to  manage  the  configuration  status  of  CPCIs.  Historically, 
configuration  management  for  computer  resources  has  focused 
only  on  the  hardware-related  elements  of  computer  systems, 
even  though  4-5%  of  the  Air  Force  budget  is  spent  on  software 
development  and  maintenance  (Ref  28:12).  But  CPCIs  do  not 
exhibit  certain  characteristics  of  CIs  upon  which  many 
established  procedures  of  configuration  management  are  based. 
Three  examples  of  this  are  as  follows.  First,  system  mal- 
functions caused  by  CPCIs  are  not  due  to  wear;  thus  correc- 
tions require  change  to  the  item's  design.  Second,  since 
CPCIs  do  not  wear  out,  there  are  no  logistics  requirements 
for  spare  parts.  Lastly,  responsiveness  to  changing  system 
requirements  Is  an  inherent  advantage  of  software;  yet,  many 
configuration  control  procedures  inhibit  this. 
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Computer  programs,  like  other  system  elements,  should 
be  configuration  managed  throughout  their  life-cycle 
(Ref  4:6,1).  Indeed,  Appendix  VIII  of  MIL-STD-483  (USAF) 
has  contained  maintenance  and  accounting  procedures  for  CPCI 
specifications  and  support  documentation  since  December  of 
1970.  Particularly  In  the  realm  of  status  accounting,  soft- 
ware should  not  be  treated  as  a "tag-along"  component  of 
hardware  (.Refs  6,12,17,32,41). 

Standardized  Software  for  CSA 

Should  an  automated  status  accounting  system  be 
standardized  for  use  by  acquisition  program  managers?  The 
Air  Force  uses  standard  mechanized  systems  to  manage  the 
configuration  status  of  equipment  already  in  the  Air  Force 
inventory  (Refs  1,37).  Such  systems  are  appropriate  because 

the  Air  Force  owns  the  equipment  being  managed,  and  status 

/ . * 

accounting  is  performed  organically.  Thus,  collecting, 
analyzing,  and  reporting  the  data  can  be  regulated. 

This  is  not  the  case  within  AFSC.  Until  configuration 
management  responsibility  is  transferred  from  AFSC  to  AFLC, 
contractors  normally  perform  the  CSA  functions  on  acquisi- 
tion items.  Although  the  contractor  can  be  directed  to  use 

' V 

an  Air  Force  provided  computer  program  or  to  use  an  organic 
Air  Force  capability  to  produce  the  reports,  these  may  not 
be  the  most  cost-effective  alternatives  CRef  5:33).  Even 
though  non-standardization  will  result  in  a proliferation 
of  status  accounting  software,  savings  can  be  realized  where 
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manufacturers  use  software  that  has  already  been  developed 
for  earlier  projects.  But  the  manufacturer's  system  should 
be  used  only  If  the  output  data  will  satisfy  Government 
requirements,  including  the  data  element  standards  of  MIL- 
STD-482A.  At  other  times,  a standard,  modifiable  design 
for  a status  accounting  system,  developed  in  advance  and 
made  available  to  contractors,  may  reduce  the  costs  of 
software  acquisition.  Moreover,  the  specifications  for  such 
a system  would  be  a useful  guide  to  help  program  managers 
identify  their  CSA  requirements. 

Purpose  and  Objectives 

The  purpose  of  this  thesis  is  to  evolve  a preliminary 
design  for  a software  system  to  record  and  report  status 
accounting  information  for  software  configuration  management. 
The  design  will  be  for  a database  processing  system  which 
wilT  consist  of  three  elements: 

a.  An  applications  program  (SOFTSAS)  that  will  super- 
vise the  recording  and  reporting  of  the  data; 

b.  A database  that  will  store  the  status  accounting 
data;  and, 

c.  A database  management  system  that  will  organize, 

* f 

control,  and  protect  the  data  In  the  database. 

Database  processing  was  selected  Instead  of  more  con- 
ventional file  processing  for  several  reasons.  First,  in  a 
database  processing  system,  application  programs  are  not  con- 
cerned with  physical  data  storage  considerations.  Thus,  the 
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system  as  a whole  is  more  adaptable  to  changing  user  require 
ments.  This  is  important  because  responsibility  for  configu 
ration  management  (_and  status  accounting)  of  a CPCI  will  be 
assigned  to  more  than  one  organization  over  the  CPCI ' s life- 
cycle,  and  each  organization  has  its  own  status  accounting 
requirements.  Second,  database  processing  facilitates 
integrating  all  of  an  organization's  data  into  one  cen- 
tralized data  bank.  Centralization  can  make  more  Informa- 
tion available  to  each  of  the  system's  users.  In  addition, 
data  redundancy  can  be  reduced,  and  data  standardization  can 
be  achieved.  Finally,  database  processing  permits  users  to 
access  and  employ  the  data  In  a variety  of  ways.  The  data- 
base is  not  structured  for  a particular  application  of  the 
data;  rather,  it  is  structured  to  accommodate  unanticipated 
queries  (Ref  16:3-5). 

* The  software  system  will  be  designed  using  current 
software  engineering  methodologies.  Software  engineering 
is  a disciplined  approach  to  software  development  and  main- 
tenance that  attempts  to  manage  software's  complexity  in 
order  to  Increase  its  reliability  and  enhance  its  cost- 
effectiveness  (Ref  7,42).  The  approach  presupposes  that  a 

* V 

software  project  will  pass  through  six  stages  during  its 
lifetime.  Once  a problem  is  Identified,  the  requirements 
for  an  acceptable  solution  to  the  problem  are  defined, 
alternative  solutions  are  developed  and  compared,  and  one 
of  them  is  selected  Csystem  requirements  analysis  stage). 
When  software  comprises  part  of  the  solution,  requirements 
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that  Identify  what  the  software  Is  to  do  are  documented 
In  a precise  and  unambiguous  way  [software  requirements 
analysis  stage).  This  documentation  Is  used  to  design  the 
algorithms,  database,  test  data,  and  overall  structure  of 
the  computer  program  [design  stage)..  These  designs  are 
then  used  to  write  the  computer  programs  [coding  stage). 

Coded  programs  are  verified  for  correctness  and  validated 
for  compliance  with  the  stated  requirements  [test  stage). 
Those  that  successfully  complete  testing  are  Implemented  and 
are  subsequently  modified  as  necessary  to  satisfy  changing 
requirements  (operations  and  maintenance  stage). 

This  thesis  provides  a description  of  the  software 
requirements  for  a software  status  accounting  system,  a 
design  of  an  overall  structure  for  the  system,  and  a design 
for  a database  to  support  it.  The  software  engineering 
methodologies  "Structured  Analysis  and  Design  Technique" 

(Ref  35),  "Structured  Design"  (Ref  11),  and  "Database 
Canonical  Form"  (Ref  20:248-290)  are  used  because  they  en- 
hance the  modifiability  of  the  computer  program.  This  is  an 
important  consideration  throughout  this  thesis  because 
AFR  800-14  directs  that  CSA  requirements  be  tailored  to  the 
specific  needs  of  each  computer  resource  acquisition  program 
(Ref  4:6,3). 

Scope 

Since  program  managers  are  given  flexibility  In  tailor- 
ing their  CSA  requirements,  a standard  set  of  CSA  reports 
cannot  be  specified  for  wide-spread  use.  The  CSA  information 
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required  by  program  managers  at  AFSC  differs  significantly 
from  that  required  by  functional  managers  at  AFLC  and  the 
using  commands.  (AFSC  reports  are  concerned  with  the  status 
of  contractual  actions;  the  others'  reports  are  concerned 
with  the  status  of  actions  against  systems  and  items  already 
in  the  inventory.)  Moreover,  the  CSA  requirements  of  pro- 
gram offices  within  AFSC  often  differ  significantly  as  well. 
Therefore,  the  software  CSA  requirements  documented  in  this 
report  are  tailored  specifically  for  the  Simulator  SPO. 
However,  a database  model  was  developed  that  has  wider  appli 
cation . 


Program  managers  are  also  given  flexibility  in  select- 
ing who  is  to  perform  the  accounting  function.  Since  AFSC 
pamphlet  800-7  recommends  that  it  be  performed  by  the  con- 
tractor developing  the  item  (even  though  program  funds  might 
be  increased),  it  is  impossible  to  anticipate  how  the  soft- 
ware will  be  implemented.  Thus,  only  a general,  preliminary 
design  for  a software  system  is  provided  in  this  thesis;  it 
is  as  independent  of  machine,  programming  language,  and 
telecommunication  considerations  as  is  practicable.  In  par- 
ticular, no  attempt  to  design  a database  management  system 
Is  made,  although  the  functions  that  it  should  perform  are 
described  and  its  interface  with  SOFTSAS  is  defined.  Only 
when  an  external  environment  Is  identified  for  the  system 
can  the  software  design  be  specified  in  more  detail. 


Plan  of  Development 

The  Simulator  SPO's  CSA  requirements  and  the  design  for 
an  application  program  to  satisfy  these  requirements  are 
documented  In  the  rest  of  this  report.  Chapter  II  presents 
an  Informal  specification  of  what  SOFTSAS  Is  to  do,  while  a 
more  rigorous  and  formal  specification  that  was  derived  using 
the  Structured  Analysis  and  Design  Technique  Is  presented  In 
Chapter  III.  Chapter  IV  contains  a software  design  which 
was  achieved  using  a methodology  known  as  Structured  Design, 
and  Chapter  V describes  a logical  model  for  software  configu- 
ration status  accounting  data.  Finally,  Chapter  VI  presents 
conclusions  and  recommendati ons . 
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1 1 Requirements  Definition 

Introduction 

The  second  stage  in  the  software  development  life-cycle 
consists  of  defining  the  software's  processing  requirements. 
During  this  stage,  the  system  requirements  identified  In  the 
first  stage  of  the  development  life-cycle  are  used  to  for- 
mulate an  unambiguous  specification  of  the  functions  that 
the  software  is  to  perform.  The  specification  is  derived 
by  focusing  on  the  interface  between  the  system  and  the 
people  who  use  it.  In  the  sections  that  follow,  an  informal 
definition  of  the  SOFTSAS  processing  requirements  is  pre- 
sented. Sources  for  these  requirements  include  military 
standards  and  regulations,  reports  on  work  done  by  others, 
and  interviews  with  AFSC  configuration  managers  (Ref  3,4,5, 
6,12,17,23,24,25,26,32,33,34,41) . 

General  Requirements 

SOFTSAS  will  be  an  application  program  designed  to  aid 
software  configuration  managers  in  tracking  CPCI  baselines 
and  the  changes  to  those  baselines.  Capable  of  executing  in 
both  a batch  and  an  interactive  mode,  its  primary  functions 
will  be  to  ma-iirtaln  a repository  for  software  status 
accounting  data  and  to  produce  pre-defined  status  accouting 
reports  and  responses  to  ad  hoc  queries  for  data. 

User  inputs  (requests),  will  consist  of  commands 
accompanied  by  required  and  optional  parameters.  SOFTSAS, 
executing  in  the  batch  mode,  will  usually  obtain  the  requests 
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from  a card  reader.  However,  other  Input  devices  may  be 
substituted.  In  the  interactive  mode,  the  requests  will  be 
obtained  from  a terminal  after  the  user  has  been  prompted 
with  a message.  No  new  request  will  be  fetched  until  the 
previous  request  has  heen  completely  processed,  and  program 
execution  will  be  terminated  when  either  an  'End'  command 
Is  encountered  or  when  a non-recoverabl e error  Is  detected 
during  batch  processing. 

SOFTSAS  output  will  consist  of  reports  and  messages. 
Three  reports  can  be  produced,  each  of  which  Is  outlined  in 
a subsequent  section  of  this  chapter.  The  messages  will  be 
generated  for  the  following  reasons: 

a.  To  respond  to  user  requests  for  Individual  Items 
of  data  from  the  database; 

b.  To  prompt  users  at  a terminal  for  Inputs; 

C.  To  notify  users  that  an  error  occurred  during  re- 
quest processing;  and, 

d.  To  notify  users  when  a request  has  been  validated 
and  then  again  when  It  has  been  processed. 

Reports  and  messages  will  be  considered  as  two  separate 
classes  of  output.  During  batch  processing,  reports  and 
messages  wilt  6e  accumulated  and  then  delivered  to  an  on- 
line printer  upon  job  termination.  During  Interactive  pro- 
cessing however,  only  the  reports  will  be  accumulated;  the 
messages  will  be  dispatched  Immediately  to  the  user's  termi- 
nal. In  either  processing  mode,  the  user  will  be  able  to 
configure  the  program's  external  environment  so  that  the 


outputs  destined  for  an  on-line  printer  can  be  directed 
Instead  to  peripheral  storage  devices  such  as  tape  or  disk 

The  repository  for  the  status  accounting  data  will  be 
a database.  A database  Is  a collection  of  data  that  can 
be  shared  among  several  applications.  As  a minimum,  the 
database  will  contain  information  required  by  the  SOFTSAS 
user  to  produce  the  status  accounting  reports.  This  Infor 
mation  will  describe: 

1.  CPCIs  being  acquired  or  maintained; 

2.  ECPs  prepared  for  the  CPCIs; 

3.  Documents  and  change  notices  supporting  the  CPCIs 


4.  Modules  that  comprise  the  CPCIs. 

More  specific  data  requirements  are  itemized  in  Chapter  V 


Report  Requirements 


Upon  user  request,  SOFTSAS  will  produce  one  or  more  of 
three  formal  reports.  These  reports  are  the  Configuration 
Index,  the  Computer  Program  Change  Report,  and  the  Software 
Tree.  Each  report  will  contain.  In  a pre-determi ned  format 
timely  status  accounting  data  for  the  CPCIs  specified  in 

the  request.  Preceding  each  report,  a title  page  will  bear 

' > 

the  following  document  Identification  data: 

a.  Issuing  agency; 

b.  Document  number; 


c.  Contract  number 


d.  CDRL  Item  number 


e.  Issue  date  and  Issue  number 


f.  CPCI  numbers  and  names;  and, 

g.  System  name. 

The  remainder  of  this  section  contains  a detailed  descrip- 
tion of  each  report. 

Configuration  Index.  The  Configuration  Index  will 
report  the  current  status  of  maintainable  and  traceable 
documents  that  support  a CPCI.  It  will  Identify  the  latest 
complete  Issue  of  the  documents  (whether  basic  or  revision), 
the  interim  changes  made  to  them,  and  the  changes  that  are 
anticipated  due  to  approved  ECPs.  Documents  issued  as  a 
series  of  volumes  will  be  reported  as  a series  of  Individual 
documents.  Figure  2-1  Illustrates  the  overall  structure  of 
the  Index  and  Identifies  the  types  of  documents  for  which 
status  accounting  records  must  be  maintained. 

The  Index  consists  of  a title  page  and  a division  for 
each  CPCI  being  reported.  Each  division  contains  one  sec- 
tion for  each  of  six  types  of  documents.  Figures  2-2,  2-3, 
and  2-4  are  examples  which  show  that  the  sections  have  simi- 
lar formats  and  consist  of  two  parts. 

The  first  part  of  each  section  identifies  the  latest 

revisions  of  documents  that  have  been  delivered  to  the  pro- 

* * 

curing  agency.  Also,  in  every  section  except  section  VI, 
it  lists  the  change  notices  (with  their  associated  ECPs) 
Issued  against  each  document  since  the  document's  last 
revision.  In  section  VI,  the  first  part  lists  the  ECPs 
delivered  with  the  Version  Description  Documents.  Specifi- 
cally, the  following  data  Is  contained  In  part  one: 
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Figure  2-1  Configuration  Index  Structure 


COMPUTER  PROGRAM  CONFIGURATION  INDEX 


Figure  2.2  Configuration  Index,  Product  Specification  Section 
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Computer  Program  Change  Report.  The  Computer  Program 
Change  Report  will  Identify  all  the  ECPs  ever  prepared 
against  a CPCI  and  will  provide  status  information  on  those 
ECPs  that  are  currently  active.  This  report  consists  of 
three  sections  for  each  CPCI  to  be  reported. 

The  first  section  is  the  Change  History.  It  contains 
an  ordered,  historical  listing  of  all  the  engineering 
changes  ever  proposed  for  the  specified  CPCI.  The  Change 
History  will  be  formatted  as  shown  In  Figure  2-5  and  will 
contain  the  following  data: 

a.  Header  - This  consists  of  section  and  CPCI  Identi- 
fication Information. 

b.  ECP  Number  - This  column  contains  an  entry  to 
identify  by  number  every  ECP  prepared  for  the  CPCI. 

c.  ECP  Title  - This  column  contains  the  titles  of  the 

ECPsV 

d.  Status  - This  column  contains  a code  for  the  cur- 
rent status  of  an  ECP.  • The  codes  that  will  be  used  are: 

1.  P - ECP  Is  being  prepared; 

1i.  S - ECP  has  been  submitted  and  Is  awaiting 

CCB  action; 

111.  A - ECP  has  been  approved  by  the  CCB; 

1v.  D - ECP  has  been  disapproved  by  the  CCB; 

v.  X - ECP  has  been  deferred  by  the  CCB; 

vi.  C - ECP  is  being  tested  by  the  contractor; 

v 1 1 . T - ECP  Is  being  organically  tested; 

vill.  I - ECP  has  been  Implemented. 
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COMPUTER  PROGRAM  CHANGE  REPORT 


Figure  2-5  Computer  Program  Change  Report,  Change  History  Section 
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e.  Date  - This  column  contains  the  date  that  the  ECP 
entered  its  current  status. 

f.  Remarks  - This  column  contains  additional  informa- 
tion which  can  be  used,  for  example,  to  identify  ECPs  which 
either  Impact  another  contractor's  configuration  item  or 
are  caused  as  a result  of  another  contractor's  ECP. 

The  second  section  of  the  Computer  Program  Change  Re- 
port is  the  Change  Status  summary.  It  contains  a concise 
summary  description  of  each  active  ECP  for  the  specified 
CPC  I . A summary  for  a particular  ECP  will  appear  In  every 
Issue  of  this  section  after  a number  has  been  assigned  to 
the  ECP  and  until  one  Issue  after  either  the  ECP  Is  disap- 
proved or  is  Implemented.  The  Change  Status  Summary  will 
be  formatted  as  shown  In  Figure  2-6  and  will  contain  the 
following  data: 

a.  Header  - This  consists  of  section  and  CPCI  identi- 
fication information. 

b.  ECP  Number,  Title  - These  entries  identify  the  ECP 
being  reported. 

c.  Priority  - This  entry  Identifies  the  priority  of 
the  ECP  as  either  "Emergency",  "Urgent",  or  "Routine". 

d.  Current  Status  - This  entry  contains  a code  for 
the  current  status  of  the  ECP  as  reported  In  the  Change 
History. 

e.  Statements  of  Problem  and  Solution  - These  entries 
contain  brief  narratives  extracted  from  the  ECP  to  describe 
the  problem  and  Its  proposed  solution. 

21 


1 
« ' 


f.  Modules  Affected  - Entries  contain  the  tree  codes 
and  names  Csee  Software  Tree  below)  of  the  computer  program 
modules  that  require  changing  In  order  to  Implement  the  ECP. 

g.  Documents  Affected  - Entries  Identify  by  type, 
number,  and  title  the  documents  that  require  changing  In 
order  to  Implement  the  ECP.  In  addition,  the  numbers  and 
delivery  schedules  of  the  CNs  that  will  accompany  the  ECP 
will  be  reported  when  known. 

h.  Related  Configuration  Changes  - Entries  cross- 
reference  the  CIs  and  other  CPCIs  that  are  affected  by  this 
change.  The  number  of  the  ECP  written  against  each  related 
Item  is  also  provided. 

i.  Change  Progress  - Entries  report  the  originally 
scheduled  date  and  the  actually  accomplished  date  for  each 
ECP  development  milestone.  All  milestones  must  be  scheduled 
when  an  ECP  enters  the  system;  unknown  dates  may  be  entered 
as  a series  of  9's.  Comments  on  an  ECP's  progress,  such  as 
rescheduled  milestones,'  can  also  be  reported. 

j.  Remarks  - This  entry  may  be  used  to  include  other 
pertinent  information  In  the  report. 

The  third  section  of  the  Computer  Program  Change  Report 

* > 

is  an  exception  report  called  the  Red  Flag  and  Activity  List. 
It  contains  a list  of  ECPs,  documents,  change  notices,  and 
program  modules  for  which  a noteworthy  event  has  occurred  or 
for  which  a suspense  date  Is  in  jeopardy.  This  List,  sorted 
In  order  of  descending  priority  of  the  Items,  Is  produced 
to  aid  the  configuration  manager  locate  those  Items  that 


most  likely  will  require  Ms  attention.  The  List  will  be 
formatted  as  shown  In  Figure  2-7  and  will  contain  the 
following  data: 

a.  Header  - This  contains  section-  and  CPCI-ldentlfi- 
catlon  Information. 

b.  Priority  - This  column  contains  the  priority  of 
the  Item  being  reported. 

c.  Item  Type  - Entries  In  this  column  Identify  the 
type  of  Item  being  reported  as  "ECP",  "Document",  "Change 
Notice",  or  "Module". 

d.  ID  Code  - This  column  contains  the  identification 
of  the  item.  Identification  code  elements  for  each  type 
of  Item  are  specified  In  Chapter  V. 

e.  Title  - This  column  contains  the  title  of  the  Item 
being  reported. 

f.  Reason  Code  - Entries  In  this  column  Indicate  why 
the  item  is  being  reported.  The  following  codes  will  be 
used: 

i.  D - Item  Is  delinquent.  An  item  is  reported 
delinquent  when  a suspense  date  Is  missed,  that  is,  when  an 
action  has  not  been  accomplished  yet  the  date  of  the  report 

+ V 

is  later  than  the  date  scheduled  for  the  action. 

11.  A - Item  requires  action.  An  item  is  reported 
as  requiring  action  when  It  will  become  delinquent  within 
30  days  of  the  date  of  the  report. 

111.  N - Item  Is  not  scheduled.  An  Item  Is  reported 
not  scheduled  when  no  suspense  date  has  been  recorded  for 


Figure  2-7  Computer  Program  Change  Report,  Red  Flag  and  Activity  Section 
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Figure  2-8  Tree  Code  Format 


it  in  the  database  or  when  the  date  has  been  represented  as 
a series  of  9's. 

iv.  C - Item  has  been  changed.  Items  are  reported 
changed  when  either  an  ECP  changes  status  or  priority,  a 
new  ECP  is  submitted,  a new  document  or  change  notice  is 
issued,  or  changes  are  made  to  the  lists  of  documents  or 
modules  affected  by  an  ECP. 

g.  Remarks  - This  column  will  normally  contain  a nar- 
rative to  explain  action  being  take  on  red  flag  items. 

Software  Tree.  The  Software  Tree  Is  a report  which 
will  describe  the  program  modules  that  comprise  specified 
CPCIs.  It  will  Identify  the  status  of  each  of  the  modules 
and  will  provide  a hierarchically-indentured  representation 
of  a general  tree  structure  used  to  model  the  functions  that 
the  modules  perform.  A Software  Tree  will  be  produced  for 
each  CPC  I specified  in  the  user's  request. 

Program  modules  are  Identified  by  unique,  three-part 
"tree  codes"  assigned  to  them  by  the  user  (Figure  2-8). 

The  first  part  of  the  code  describes  the  function  that  the 
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module  performs.  Each  of  the  five  character  positions  re- 
presents a corresponding  level  In  the  tree,  and  the  contents 
of  the  concatenated  positions  specify  a unique  function  that 
SOFTSAS  modules  will  perform.  The  second  part  of  the  code 
distinguishes  between  the  members  of  a group  of  modules  that, 
together,  perform  the  specified  function.  The  third  part  of 
the  code  specifies  the  current  revision  of  the  module  being 
descrl bed . 

The  Software  Tree  consists  of  two  sections.  The  first 
section  lists  the  elements  Cnodes)  that  make  up  the  first 
five  levels  of  the  tree  structure  Csee  Figure  2-9).  These 
nodes  are  established  by  the  user  according  to  the  following 
guldel ines : 

a.  Each  node  at  the  first  level  identifies  a different 

CPCI; 

b.  Each  node  at  the  second  level  identifies  an  oper- 
ating mode  as  either  "real-time"  or  " non-real -time" ; 

c.  Each  node  at  the  third  level  specifies  an  operating 
class  as  either  operational,  support,  or  test  (Ref  4:10,1); 

d.  Each  node  at  the  fourth  level  specifies  an  operating 
sub-class  as  deemed  appropriate  by  the  contractor  (DOC  STDS 
48-49) 

3.  Each  node  at  the  fifth  level  specifies  a function 
as  deemed  appropriate  by  the  contractor. 

The  second  section  specifies  the  tree  at  the  s^xth  and 
seventh  levels.  It  contains  on  subsection  for  each  "func- 
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SOFTWARE  TREE 


Software  Tree,  Functional  Description  Section 


tlon"  in  order  to  describe  specific  characteristics  of  the 
modules  supporting  that  function.  As  Illustrated  In  Figure 
2-10,  each  suhsection  contains  the  following  data: 

a.  Header  - This  consists  of  function  Identification 
information; 

b.  Module  Code  - This  column  contains  the  tree  codes 
of  the  modules  which,  together,  perform  the  designated 
function; 

c.  Revision  Letter  and  Date  - These  columns  contain 
the  current  revision  identifier  for  each  module  and  the 
date  that  the  revision  was  delivered  to  the  procuring 
activity; 

d.  Source  and  Object  Media  Numbers  - These  columns 
contain  the  identifiers  of  the  devices  on  which  the  module 
is  stored  in  its  source  and  object  forms,  respectively. 

' e.  Source  and  Object  File  Addresses  - These  columns 
contain  the  addresses  of  the  source  and  object  files  on  the 
storage  media; 

f.  Related  Documents  - This  column  contains  the 
identifiers  of  documents  that  specifically  address  the 
operation,  test,  or  maintenance  of  a listed  module; 

* f 

g.  Description  - This  column  contains  the  names  of 
the  listed  modules. 

Input  Requirements 

Inputs  to  SOFTSAS  will  consist  of  user  requests  to 
operate  on  the  database  in  some  way.  Since  discussions 
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about  the  database  appear  In  this  and  In  subsequent  sections 
of  this  paper,  some  of  the  terms  used  to  describe  the  struc- 
ture of  the  database  will  be  described  here.  Then,  a de- 
scription of  legal  SOFTSAS  requests  will  be  presented. 

Basic  Terms.  The  following  terms  will  be  used  when 
describing  the  logical  structure  of  the  database,  that  is, 
the  structure  as  viewed  by  the  applications  programmer: 

1.  Field  - A field  Is  the  smallest  unit  of  named  data. 

2.  Record  - A record  Is  a named  collection  of  ordered 
fields. 

3.  Database  File  - A database  file  Is  a logical  col- 
lection of  all  occurrences  (Instances)  of  a given  type  of 
database  record. 

4.  Database  - A database  Is  a collection  of  multiple 

record  types  (database  files). 

. * 

5.  Realm  - A realm  Is  a defined  subset  of  database 
records . 

6.  Primary  Key  - A primary  key  is  one  or  more  fields 
that  can  be  used  to  differentiate  between  each  of  the 
records  In  a database  file. 

7.  Secondary  Key  - A secondary  key  Is  one  or  more 
fields  that  can  be  used  to  Identify  a group  of  records  in 
a database;  however,  It  cannot  distinguish  between  the 
records  In  a group. 

User  Requests.  User  requests  consist  of  a sequence  of 
words  and  symbols  that  resemble  an  English  sentence  written 
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In  the  Imperative  mood.  Table  I lists  the  types  of  words 
and  symbols  that  can  be  used.  Each  request  begins  with  a 
command  word.  The  command  word  Is  followed  by  any  required 
and  optional  parameters,  according  to  syntactic  rules 
established  for  that  command.  The  rules  for  each  type  of 
request  are  presented  below  In  a metalanguage  which  utilizes 
the  following  conventions: 

a.  Words  appearing  In  upper-case  letters  are  a required 
part  of  a request  or  clause; 

b.  Words  appearing  in  lower-case  letters  are  abstrac- 
tions for  data  to  be  supplied  by  the  user; 

c.  Brackets  enclose  a group  of  words  or  clauses  from 
which  one  must  be  singled  out  for  use  In  the  request; 

d.  Braces  enclose  a word  or  clause  that  may  be  re- 
peated in  the  request; 

e.  Parentheses  enclose  a word  or  clause  that  may  be 
Included  In  the  request  at  the  user's  options. 

* V 

The  remainder  of  this  section  describes  the  legal  SOFTSAS 
requests . 

1.  Open . The  OPEN  request  (.Fig  2-111  Instructs 
SOFTSAS  to  prepare  the  named  database  realm  for  processing. 
This  request  must  be  Issued  before  any  occurrence  of  a 
record  In  the  realm  can  be  accessed.  The  OPEN  request  must 
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OPEN  realm-name  SETTING  USER  * user-identifier 
and  MODE  * [ READ,  EXCLUSIVE_WRITE,  PROTECTED_WRITE] 

Figure  2-11  OPEN  Request 
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Figure  2-12  CREATE  Request 


include  a SETTING  clause  which  is  used  to  specify  the 
identity  of  the  user  and  the  mode  in  which  he  wishes  to 
access  the  realm. 

Specifying  an  access  mode  aids  SOFTSAS  in  protecting 
the  integrity  of  the  database.  In  order  to  process  an  up- 
date request  such  as  CREATE,  DELETE,  or  MODIFY,  the  user 
must  specify  either  the  EXCLUSIVE-WRITE  or  the  PROTECTEX- 
WRITE  mode.  A realm  that  is  being  accessed  in  the 
EXCLUSIVE-WRITE  mode  by  a program  cannot  be  accessed  by  a 
concurrently  operating  program.  A realm  that  is  being 
accessed  in  the  PROTECTED-WRITE  mode  by  a program  can  only 
be  Opened  In  the  READ  mode  for  another  program. 

Upon  encountering  an  OPEN  request,  SOFTSAS  will  verify 
that  the  named  realm  exists  and  that  the  user  is  authorized 
to  access  It.  SOFTSAS  will  then  attempt  to  prepare  the 
realm  in  the  requested  mode  for  the  user.  If  an  attempt 
falls,  another  attempt  will  be  made  after  a short  delay. 

* V 

2.  Create.  The  CREATE  request  (Fig  2-12)  Instructs 
SOFTSAS  to  add  a new  occurrence  of  a record  to  the  database. 
The  request's  parameters  must  specify  the  name  of  the  record 
to  be  created  and  the  value  to  be  used  as  the  primary  key 
for  the  occurrence.  The  parameters  may  also  specify  other 
data  to  be  stored  in  the  record  as  well. 
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DELETE  record-name 

(.WHERE  fteld-name  [EQ,  GE,  GT,  LE,  LT,  NQ]  operand 
(.{[AND,  OR]  field-name  [EQ,  GE,  GT,  LE,  LT,  NQJ 

operand}) ) 

Figure  2-13  DELETE  Request 

SOFTSAS  will  use  the  record's  name  to  obtain  Its  de- 
scription from  the  database.  It  will  then  reserve  and  for- 
mat storage  space  as  required,  sotrlng  all  data  provided  by 
the  user  In  the  request  and  recording  all  values  for  key 
fields  (both  primary  and  secondary)  In  the  appropriate 
database  Indexes. 

3.  Delete.  The  DELETE  request  (Fig  2-13)  Instructs 
SOFTSAS  to  remove  occurrences  of  a named  record  from  the  data- 
base. Unless  a WHERE  clause  Is  provided  as  a parameter, 
SOFTSAS  will  delete  all  occurrences  of  the  named  record  and 
all  pointer  to  them.  A WHERE  clause  contains  search  criteria 
(values  for  key  fields)  used  by  SOFTSAS  to  limit  the  effect 

of  a database  operation  to  certain  occurrences  of  a record. 
When  a WHERE  clause  Is  present,  SOFTSAS  will  delete  only 
those  occurrences  of  the  record  whose  key  fields  contain 
values  that  satisfy  the  search  criteria. 

Upon  encountering  a DELETE  request,  SOFTSAS  will  first 
locate  and  then  erase  all  data  associated  with  qualified 
record  occurrences. 

4.  Modify.  The  MODIFY  request  CFIg  2-141  Instructs 
SOFTSAS  to  alter  the  contents  of  occurrences  of  a named  re- 
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cord,  the  request  must  alos  Include  a SETTING  clause.  The 
SETTING  clause  will  contain  the  names  of  the  fields  to  be 
modified  and  the  new  data  that  they  are  to  contain.  Any 
fields  of  a record  may  be  changed  except  for  primary  key 
fields.  The  user  also  has  the  option  of  specifying  a WHERE 
clause.  This  clause  has  the  same  effect  here  as  It  does  for 
the  DELETE  request. 

Upon  encountering  a MODIFY  request,  SOFTSAS  first  lo- 
cates the  occurrences  to  be  modified  and  then,  one  occur- 
rence at  a time,  updates  the  fields  specified  in  the  request. 

5.  Produce.  The’ PRODUCE  request  (Fig  2-15)  instructs 
SOFTSAS  to  build  and  print  one  or  more  of  the  status 
accounting  reports  described  earlier  in  this  chapter.  The 

PRODUCE'  report-name  ({AND  report-name}) 

(WHERE  field-name  [EQ,  GE,  GT,  LE,  LT,  NQ]  operand 
(HAND, OR]  field-name  [EQ,  GE,  GT,  LE,  LT,  NQ] 

operand} II 

Figure  2-15  PRODUCE  Request 


MODIFY  record-name 

SETTING  field-name  » operand  ({AND  f lei d-name=operand} ] 
(WHERE  field-name  {EQ,  GE,  GT,  LE,  LT,  NQ]  operand 
({[AND, OR]  field-name  [EQ,  GE,  GT,  LE,  LT,  NQ] 

operand} I) 

Figure  2-14  MODIFY  Request 
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request  will  specify  which  reports  are  to  be  produced  and 
may  Include  a WHERE  clause  to  restrict  the  reporting  to  cer- 
tain CPCIs.  Otherwise,  the  reports  will  contain  staus 
accounting  Information  for  each  of  the  CPCIs  in  the  database. 

6.  Print.  The  PRINT  request  (Fig  2-16)  instructs 
SOFTSAS  to  retrieve  specific  items  of  status  accounting  data. 

The.  request  not  only  names  the  data  to  be  retrieved  but  also 
dictates  the  format  in  which  it  Is  to  be  printed. 

Three  elements  of  the  request  identify  the  data  to  be 
retrieved.  First,  the  user  will  provide,  in  a WHERE  clause, 
the  name  of  the  record  to  be  accessed.  In  addition,  the 
user  can  specify  search  criteria  in  the  WHERE  cluase  that 
restrict  request  processing  to  certain  occurrences  of  the 

I 1 

named  record.  Finally,  the  user  can  ask  for  all  the  data 

stored  In  qualified  occurances  of  the  record  or,  by  sped- 

* / 

fying  field  names,  can  ask  for  only  a subset  of  that  data. 

Two  elements  of  the  request  dictate  the  format  for  the 
output  data.  All  the  data  retrieved  from  a single  occurrence 
of  a record  will  constitute  one  line  of  output.  In  each 
line,  the  data  will  be  presented  In  the  order  that  their 


PRINT  (ifield-name  ({AND  field-name}),  RECORD]) 
CS0RTED_0N  [ASCENDING,  DESCENDING]  field-name 
((AND  [ASCENDING,  DESCENDING]  field-name})) 

(WHERE  RECORD  * record-name  ({AND  f lei d-name»operand } ) 

Figure  2-16  PRINT  Request 
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PRINT  ECP I D AND  ECP_MILESTONE_NAME  AND  ECP_MILESTONE_ 

SCHED_DATE  SORTED_ON  ASCENDING  ECP_MILESTONE_SCHED_DATE  AND 
ASCENDING  ECP_ID  WHERE  RECORD  = ECP_MILESTONES  AND 
CPCI  ID  *XXX ; 


ECP-# 

MILESTONE 

DUE-DATE 

QOOOl 

Preparation 

1 Jan  78 

00002 

Preparation 

5 Jan  78 

00002 

Submittal  to  CCB 

20  Jan  78 

00001 

Submittal  to  CCB 

28  Jan  78 

00003 

Preparation 

28  Jan  78 

00002 

CCB  action 

10  Feb  78 

PRINT  E C P I D AND  ECP_MILESTONE_SCHED_DATE  SORTED_ON 

ASCENDING  ECP_ID  WHERE  RECORD  = ECP  AND  CPCI_ID  =XXX ; 


ECP-# 

DUE  DATE 

MILESTONE 

00001 

1 Jan  78 

Preparation 

00001 

28  Jan  78 

Submittal  to  CCB 

00002 

5 Jan  78 

Preparation 

00002 

.20  Jan  78 

Submittal  to  CCB 

00002 

10  Feb  78 

CCB  Action 

00003 

28  Jan  78 

Preparation 

Figure  2-17  Sample  Input  and  Output  for  PRINT  Requests 


DESCRIBE  Ct COMPLETELY,  LIMITED,  record-name 
C{ AND  record-name}  1 (^COMPLETELY) , 
field-name  C t AN D field-name})]  1 

Figure  2-18  DESCRIBE  Request 

corresponding  fields  were  named  in  the  request.  If  fields 
were  not  named  in  the  request,  the  data  will  be  presented  in 
the  order  that  the  fields  were  defined  when  the  structure  of 
the  database  was  created.  Besides  controlling  the  order  in 
which  the  data  will  be  presented  in  a line,  the  user  may 
specify  that  the  lines  of  output  be  sorted  on  the  contents 
of  one  or  more  fields  In  the  record.  However,  If  no  S0RTED_ 
ON  clause  is  provided,  the  lines  will  be  written  out  in  the 
order  the  record  occurrences  were  accessed. 

The  examples  in  Figure  2-17  illustrate  how  the  format 
of  the  PRINT  request  affects  the  format  of  its  output. 

7.  Descri be . The  DESCRIBE  request  (Fig  2-18)  in- 
structs SOFTSAS  to  provide  Information  to  the  user  about  the 
logical  structure  of  the  database.  The  request  can  be  sub- 
mitted in  one  of  six  forms.  Figure  2-19  contains  a list 
of  the  forms  and  the  outputs  they  produce. 

The  majority  of  responses  to  DESCRIBE  requests  will 
consist  of  record  descriptions  or  field  descriptions  or 
both.  The  description  of  a record  consists  of: 

a.  The  name  of  the  record;  o 

b.  The  names  of  the  fields  that  comprise  It; 

c.  The  number  of  times  the  record  occurs  in  the  realm; 
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Figure  2-19  Types  of  DESCRIBE  Requests 


CLOSE  realm-name 


Figure  2-20  CLOSE  Request 


d.  The  numher  of  bytes  of  storage  space  that  the  re- 
cord occupies;  and, 

e.  The  Identity  of  the  record's  primary  and  secondary 
key  fields. 

The  description  of  a field  consists  of: 

a.  The  name  of  the  field; 

b.  The  length  of  the  field  in  bytes; 

c.  The  type  of  data  the  field  contains;  and, 

d.  The  relative  position  the  field  occupies  within 
the  record. 

8.  Close.  The  CLOSE  request  (.Fig  2-20)  instructs 
SOFTSAS  to  revoke  the  user's  access  to  the  named  realm. 

The  request,  in  effect,  cancels  a previous  OPEN  request. 

9.  End . The  END  request  (Fig  2-21)  instructs  SOFTSAS 
to  terminate  job  execution.  This  request  must  be  included 
in  the  user's  input  stream,  and  any  requests  submitted 
after  the  END  request  will  not  be  processed. 

Data  Management  Requirements 

In  a database  processing  environment,  a database  manage- 


Figure  2-21  END  Request 


ment  system  (.DBMS)  Interfaces  between  the  database  and  the 
application  programs  to  disencumber  the  programs  of  data 
storage  details  and  to  protect  the  data  from  misuse  and 
abuse.  User  application  programs  Interact  with  the  DBMS 
only  to  update  and  retrieve  data.  Other  data  management 
functions  such  as  data  base  construction  and  security  are 
not  entrusted  to  the  user.  Rather,  they  are  performed  by  a 
single  manager,  called  the  Database  Administrator  (DBA), 
who  uses  special  utility  programs  furnished  with  the  DBMS. 

In  either  case,  the  data  itself  Is  referenced  In  logical, 
or  symbolic,  terms. 

Although  It  is  beyond  the  scope  of  this  thesis  to 
select  or  design  a DBMS  to  support  SOFTSAS,  the  requirements 
that  SOFTSAS  will  levy  on  its  DBMS  will  be  presented  here. 

Data  Manipulation.  SOFTSAS  will  generate  database 
manipulation  requests  expressed  In  terms  of  logical  data 
relationships.  The  DBMS  must  transform  these  requests 
into  basic  input/output  operations  on  the  database  file, 
dispatch  them  to  the  host  operating  system,  and  then  report 
back  to  SOFTSAS  the  status  of  the  request's  outcome.  The 

following  are  descriptions  of  the  data  manipulation  func- 

* / 

tions  to  be  performed  by  the  DBMS: 

a.  Find  - The  purpose  of  this  function  is  to  locate, 
and  to  return  unique  Identifiers  for,  occurrences  of  re- 
cords that  satisfy  a specific  search  criterion.  SOFTSAS 
will  provide: 

1.  The  name  of  the  record  to  be  located; 


ii.  A relational  expression  consisting  of  the  name 
of  a key  field,  a value  for  the  key  field,  and  a relational 
operator  code;  and, 

iii.  The  address  and  size  of  a buffer  to  contain  the 
identifiers. 

b.  Open  - The  purpose  of  this  function  is  to  prepare 
a database  realm  for  processing  given  the  name  of  the  user, 
the  name  of  the  realm  he  wishes  to  access,  and  the  type  of 
access  protection  he  needs. 

c.  Close  - The  purpose  of  this  function  is  to  termi- 
nate a user's  access  to  a realm. 

d.  Get-dict  - The  purpose  of  this  function  is  to 
retrieve  specific  information  about  the  logical  structure 

4 

of  the  database.  SOFTSAS  will  specify  exactly  what  infor- 
mation is  needed  and  the  address  and  size  of  a buffer  in 
which  to  store  it. 

e.  Get-data  - The  purpose  of  this  function  is  to 
retrieve  status  accounting  data  fro-m  the  database  given: 

1.  A record  occurrence  identifier  that  was 
previously  "found"; 

ii.  The  names  of  the  fields  in  the  record  to  be 
queried;  and, 

iii.  The  address  and  size  of  a buffer  to  hold  the 
retrieved  data. 

f.  Update  - The  purpose  of  this  function  is  to  change 
data  which  had  been  stored  in  the  database.  SOFTSAS  will 
supply  a record  occurrence  Identifier  that  was  previously 
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"found",  the  names  of  the  fields  to  be  changed,  and  the 
address  of  a buffer  that  contains  the  new  data. 

g.  Add-new  - The  purpose  of  this  function  Is  to  store 
a new  occurrence  of  a record  In  the  database  and  to  create 
all  the  appropriate  linkages  and  addressing  facilities. 
SOFTSAS  will  supply  the  name  of  the  record  to  be  added,  the 
names  of  fields  in  the  record  for  which  the  user  has  pro- 
vided data,  and  the  address  of  a buffer  containing  the  status 
accounting  data.  Unique  data  values  must  be  provided  for 
the  record's  primary  key  field(s). 

h.  Delete  - The  purpose  of  this  function  is  to  remove 
an  occurrence  of  a record  from  the  database  and  to  erase 

all  linkages  to  It.  The  Identifier  of  the  record  occurrence 
will  be  provided  by  SOFTSAS. 

Data  Description.  To  reference  the  status  accounting 
data,  SOFTSAS  will  use  a logical,  or  symbolic,  representa- 
tion of  the  database.  In  this  way,  the  program  will  not  be 
affected  by  changes  to  the  database's  physical  structure. 

The  logical  model  of  the  database  will  be  constructed 
(by  the  Database  Administrator)  by  using  a data  description 
language  (.DDL).  A DDL  provides  the  means  to  assign  names 
and  types  to  fields  and  to  define  the  way  that  fields  are 
grouped  into  records.  In  addition,  a DDL  is  used  to  desig- 
nate primary  and  secondary  keys,  to  establish  inter-record 
relationships,  and  to  impose  privacy  controls.  The  vocabu- 
lary for  the  DDL  will  not  be  known  until  a DBMS  has  been 
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selected  to  support  SOFTSAS.  This  is  because  most  database 
management  systems  provide  their  own  DDL  to  represent  the 
frequently  unique  constructs  used  by  the  DBMS  In  organizing 
Its  database. 

A utility  program  will  need  to  be  acquired  with  the 
SOFTSAS  DBMS  to  build  a dictionary  of  data  definitions  from 
a set  of  DDL  specifications.  A similar  program,  capable  of 
modifying  an  existing  dictionary,  must  also  be  acquired. 

The  dictionary  will  form  part  of  the  database,  and  Its 
information  will  be  directly  available  to  the  DBMS  and  In- 
directly available  to  SOFTSAS  (via  the  Get-dict  database 
function) . 

Data  Security.  SOFTSAS  and  the  DBMS  will  protect  the 
status  accounting  data  to  the  extent  that  software  is  able 
to  do  so.  The  threats  of  most  concern  are  unauthorized 
access  to  the  data  and  loss  of  the  data.  Unauthorized 
access  to  the  data  refers  to  illegal  data  acquisition  or 
modification,  including  modification  to  the  structure  of 
the  database.  Data  can  be  lost  because  of  natural  hazards 

(fire,  flood,  or  earthquake),  human  hazards  (physical 

\ 

damage  due  to  dropping  a disk  pack),  and  operating  hazards 
(program  error  or  bad  Input). 

To  protect  against  Illegal  data  acquisition  and  modi- 
fication, SOFTSAS  will  validate  all  user's  requests  against 
a list  containing  the  names  of  legal  users  and  the  types  of 
requests  each  is  authorized  to  submit.  In  addition,  some 
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users  who  may  he  authorized  to  submit  a particular  SOFTSAS 
request  may  not  be  authorized  access  to  all  the  data  In  the 
database.  Therefore,  the  DBMS  will  check  each  database  re- 
quest against  privacy  controls  Imposed  on  the  data  when  the 
database  was  defined. 

To  protect  against  loss  of  data,  a utility  program 
will  need  to  he  acquired  with  the  DBMS  to  provide  a database 
backup  and  recovery  capability.  All  database  modifications 
will  be  recorded  In  a journal,  and  a copy  of  the  database 
will  periodically  be  created  and  saved.  When  data  is  lost, 
a copy  of  the  database  that  was  created  before  the  problem 
occurred  will  replace  the  damaged  database.  Then,  selected 
modifications  (called  after-images)  can  be  reapplied  from 
the  journal  to  complete  the  recovery  process.  The  DBA 
should  be  responsible  for  the  saving,  restoring,  and 
recovering  of  the  status  accounting  data. 

Summary 

This  chapter  has  presented  an  informal  definition  of 
the  SOFTSAS  processing  requirements.  Briefly  stated, 

SOFTSAS  must  maintain  status  accounting  data  and  provide 
formal  reports  and  responses  to  ad  hoc  queries. 

* s 

These  requirements  are  the  product  of  the  second  stage 
of  the  software  development  life-cycle  and  form  the  basis 
for  a formal  functional  specification  using  SADT  models  In 


Chapter  III. 


46 


Ill  Formal  Functional  Specification 
Introduction 

The  formal  functional  specification  of  the  SOFTSAS 

% 

system  is  presented  as  two  models  depicting  "what"  the  sys- 
tem is  to  do.  The  models  were  developed  using  a disciplined 
approach  to  functional  analysis  introduced  by  Softech,  Inc., 
as  part  of  their  Structured  Analysis  and  Design  Technique 
(SADT)  (Ref  35). 

The  purpose  of  the  models  is  to  provide  an  unambiguous 
specification  of  the  system.  The  system  is  represented  by 
an  organized  sequence  of  well-defined,  interrelated  diagrams. 
SADT  uses  the  principle  of  top-down  systems  design  to  de- 
compose a very  general  view  of  the  system  into  successive 
levels  of  smaller,  component  views  called  modules.  As  the 
modules  at  each  level  are  decomposed,  more  details  about 
the  system  are  exposed.  This  process  continues  until  a 
level  is  reached  at  which  the  modules  are  small  enough  such 
that  they  can  be  easily  understood  and  their  Interfaces  can 
be  completely  delineated. 

Since  systems  can  be  thought  of  as  a collection  of 
things  (data). and  the  processes  that  act  on  them  (acti- 
vities), SADT  requires  that  a system  be  modelled  twice.  In 
one  model,  "actlgrams"  emphasize  the  activities  with  data 
Items  Interfacing  between  them.  In  the  other  model, 
"datagrams"  emphasize  the  data  with  activities  Interrelating 
them.  Together,  these  models  provide  a graphic  representa- 
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tion  that  clearly  reveals  the  relationships  between  all 
the  elements  and  functions  of  the  system. 

The  rest  of  this  chapter  contains  the  SOFTSAS  activity 
and  data  models  with  supporting  text  for  each.  Preceeding 
each  model  is  a "node  index"  which  gives  an  overview  of  the 
decomposition  structure  of  the  system.  Instructions  for 
reading  the  SADT  "diagramming  language"  are  contained  in 


Appendix  A and  are  further  described  in  Refs.  35  and  36. 
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Activity  Model 


Node 


Title 


A-Q 

Maintain  Status  of  Software  Configuration 

AO 

Maintain  Status  of  Software  Configuration 

A1 

Analyze  User  Request 

All 

Check  User  Request 

A12 

Check  User  Authorization 

A13 

Report  Status  of  Outcome 

A14 

Determine  Output  Data  Formats 

A15 

Generate  Database  Requests 

A16 

Generate  Messages 

A2 

Process  Database  Requests 

A3 

Produce  Reports 

A31 

Dispatch  Report  Formats 

A32 

Build  Configuration  Index 

A321 

Produce  Section  Header 

A322 

Describe  Current  Document  Configuration 

A323  Describe  Scheduled  Changes 

A324  Build  Title  Page 

A33  Build  Computer  Program  Change  Report 

A331  Produce  Change  History  Section 

A332  Produce  Change  Status  Section 

A333  Produce  Red  Flag  and  Activity  Section 

A34  Build  Software  Tree 


A341 

Describe  Software  Functions 

A342 

Produce  Module  Descriptions 

A4 

Compose  Query  Response 

A41 

Sort  Data  Items 

A-42 

Compose  PRINT  Response 

A43 

Compose  DESCRIBE  Response 

A5 

Put  Outputs 

A51 

Determine  Message  Destination 

A52 

Deliver  Reports  to  Printer 

A53 

Deliver  Messages  to  Printer 

A54 

Deliver  Messages  to  Terminal 
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These  models  were  developed  as  a tool  for  systems 
analysts  who  are  tasked  with  designing  a "software  status 
accounting"  applications  program  to  be  called  SOFTSAS. 
SOFTSAS  will  be  used,  by  offices  responsible  for  tracking 
CPCI  baselines,  to  maintain  data  which  identifies  the 
status  of  a software  system's  configuration.  The  system 
should  insure  that  only  authorized  users  are  allowed  access 
to  the  system's  data  and  that  retrieved  data  can  be  pre- 
sented to  the  user  in  a meaningful  format. 

A-0  Text 

Users  (C2)  interface  with  SOFTSAS  via  submitted  re- 
quests (Cl)  which  control  the  operation  of  the  system. 

These  requests  Instruct  SOFTSAS  to  record  new  status 
accounting  data  and  to  relate  this  data  back  to  the  user 
in  the  form  of  formal  reports  (01)  or  of  formatted  responses 
to  ad  hoc  queries  for  specific  information  (02). 


User 


Maintain  Status  of  Software  Configuration 


r 


I 


I ( 


i 
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AO  Text 

Submitted  user  requests  Dili  are  evaluated  by  the 
"Handle  User  Request"  activity  Cl).  If  the  user  (_1C2) 
submits  a request  tfiat  does  not  meet  the  validation 
criteria  ClCl,  1C2),  the  request  is  rejected  and  the  user  is 
notified  Cl 04 ) . Otherwise,  (1)  directs  that  the  status 
accounting  data  C2I1,  202)  be  stored  or  retrieved  as  per 
request  (1Q2).  In  addition,  for  data  retrieval  requests, 

(1)  determines  the  output  formats  (101)  to  be  used  by  (3) 
and  (4). 

"Process  Database  Request"  (2)  is  a sub-system  (Data- 
base Management  System)  which  accesses  and  maintains  the 
primary  database  (.213,  204)  inresponse  to  database  requests 
( 2C1 ) . New  user  data  (211)  are  obtained  from  (1)  and 
retrieved  data  (202)  are  dispatched  to  the  output  formatting 
activities  (3,  4).  This  activity  (2)  also  makes  back-up 
copies  (201)  of  the  database  and  database  modifications 
journal  for  future  use  as  (211)  should  recovery  from  inad- 
vertant  data  loss  be  required.  An  indicator  (2C1)  is  re- 
turned to  SOFTSAS  to  signal  if  the  database  request  was 
successfully  processed.  Activity  (2)  is  not  modelled 
further  in  this  report  since  its  specifications  are  beyond 
the  scope  of  this  thesis.  However,  the  requirements  that 
SOFTSAS  levies  on  (2)  are  discussed  in  Chapter  II. 

"Produce  Report"  (3)  uses  the  retrieved  status 
accounting  data  (311)  and  specified  formatting  requirements 


53 


I 


•MIMMm 


r 


(3C1 ) to  build  formal  status  accounting  reports  (3Q1). 
"Compose  Query  Response"  C4 1 uses  the  retrieved  data  Oil) 
and  specified  formatting  requirements  (4C1)  to  build  re- 
sponses (.401 ) to  ad  hoc  user  requests  for  data. 

All  Information  (511,  512,  513)  prepared  for  the  user 
by  SOFTSAS  are  outputted  by  (5)  in  the  form  of  formal  re- 
ports (501)  and  user  messages  (502). 
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Figure  3-3  Analyze  User  Request 
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A1  Text 

A submitted  request  (111).  is  checked  by  Cl)  for  legal 
request  syntax  ClCl).  If  it  is  a legal  SOFTAS  request  C2 I 1 } » 
it  is  checked  against  established  user  authorizations  (2C1) 
by  C2)  to  insure  that  the  user  C2C2)  is  authorized  to  make 
the  request.  Invalid  requests  (.101,  201)  are  rejected,  and 
the  user  is  notified  by  (6). 

For  SOFTSAS  data  retrieval  requests  (4C1),  output  data 
formats  (401)  are  prepared  by  (4)  and  dispatched  to  the 
activity  responsible  either  for  building  formal  reports  or 
for  constructing  query  responses.  Report  formats  are  pre- 
determined (4C2),  whereas  query  response  formats  are 
specified  in  the  data  retrieval  request  (4C1)  itself. 

"Generate  Database  Requests"  (5)  prepares  database 
commands  and  parameters  (501,  502).  It  uses  the  infomation 
provided  by  the  valid  SOFTSAS  requests  (502)  or,  in  the 
case  of  a PRODUCE  request,  it  uses  the  predetermined  data 
requirements  of  the  reports  to  be  built  (5C1). 

Status  indicators  (3C1,  3C2)  are  used  by  (3)  to  report 
back  to  the  user  the  final  outcome  of  each  valid  request 
(301).  This  data  (613),  together  with  user  prompts  (611) 
and  error  notifications  (602),  is  embodied  in  messages  (04) 
prepared  by  (6)  according  to  predetermined  formats  (6C1). 
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Figure  3-4  Produce  Reports 


A3  Text 

Report  formats  ClCl]  are  dispatched  by  (11  to  the 
appropriate  report-generating  activity  (2,  3,  41.  There, 
the  formats  (2C1,  3C1,  4C1 1 control  how  the  retrieved 
status  accounting  data  (211,  311,  411)  Is  edited  for  out- 
put (2Q1,  302,  402).  The  outcome  status  of  the  report 
building  activity  is  delivered  at  (202,  301,  401). 


Configuration 
Index  Formats 


Figure  3-5  Build  Configuration  Index 


A32  Text 
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The  Configuration  Index  (GU ).  ts  built  according  to 
predetermined  formats  (Cl).  It  consists  of  a title  page 
(401)  and  a division  for  each  CPCI  to  be  reported.  Each 
division  consists  of  six  sections.  Retrieved  data  per- 
taining to  a single  CPCI  (II)  will  comprise  each  division 
of  the  Index. 

Activity  'Build  Title  Page'  (41  will  be  performed  once 
for  each  issue  of  the  Index.  The  other  activities  (2,  3, 

4)  will  combine  to  produce  a single  section  and  will  be  per- 
formed six  times  for  each  CPCI  being  reported. 


A33  Text 

The  Computer  Program  Change  Report  (Oil  Identifies  the 
status  of  engineering  changes  proposed  for  CRCI.  For  each 
CPCI  being  reported.  It  consists  of  a Change  History  sec- 
tion (1011,  a Change  Status  section  (2Q1 ) , and  a Red  Flag 
and  Activity  section  (.301). 

Activity  (1)  produces  the  Change  History  section  (101) 
which  contains  a list  of  all  the  change  (111)  ever  proposed 
against  a specified  CPCI  (1C1). 

Activity  (2)  produces  the  Change  Status  section  (201) 
which  contains  information  about  each  active  change  pro- 
posal (211)  for  a specified  CPCI  (2C1). 

Activity  (3)  produces  the  Red  Flag  and  Activity  sec- 
tion (301)  which  Identifies  ECPs,  documents,  and  change 
notices  (311)  that  have  missed  a suspense  date,  that  are 
within  30  days  of  missing  a suspense  date,  or  that  have 
not  recorded  a suspense  date  for  a milestone.  In  addition, 
the  section  identifies: 

1.  ECPs  that  have  changed  status  or  priority; 

2.  Documents  or  change  notices  issued  since  the  last 
report  was  produced;  and, 

• t 

3.  Changes  to  lists  of  documents  and  modules  which  are 
affected  by  an  ECP. 
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A34  Text 

The  Software  Tree  (.Oil  Is  a two-sectton  report  that 
describes  the  configuration  and  status  (11)  of  the  modules 
that  comprise  a specified  CPC  I . The  function  section  (101) 
is  produced  by  (1)  and  contains  a hierarchically-indentured 
description  of  the  functions  (111)  performed  by  the  modules 
The  module  section  (2Q1)  Is  produced  by  (2)  and  contains 
descriptions  of  the  modules  (211)  that  perform  each  of 
the  described  functions.  Construction  of  the  Software 
Tree  (01)  is  controlled  by  predetermined  formats  (Cl), 
and  identifiers  of  the  CPCIs  to  be  reported  comprise  a 
part  of  the  formats. 
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Print"  Output 


Figure  3-8  Compose  Query  Response 


A4  Text 

Query  responses  (Oil  result  from  either  a user  PRINT 
(1C1)  or  DESCRIBE  C2C2)  request.  PRINT  responses  (2Q1) 
consist  of  status  accounting  data  Clll)  that  have  been 
sorted  by  (1)  based  on  certain  field  values  (1C)  and  then 
edited  by  (2)  based  on  formatting  guidelines  (2C1)  speci- 
fied in  the  user's  request.  DESCRIBE  responses  (301)  con- 
sist of  descriptions  (311)  of  status  accounting  data  items; 
the  descriptions  are  formatted  by  (3)  according  to  pre- 
determined instructions  (3C1).  The  outcome  status  of  query 
processing  is  provided  at  (202,  302). 


A5  Text 

SOFTSAS  outputs  consist  of  reports  C201).  and  messages 
(3QI,  401).  All  reports  C2I1)  are  delivered  to  the  on- 
line printer  by  (_2).  The  dettnatton  ClQT)  of  messages 
(311,  312,  411,  412)  is  determined  by  (1)  based  upon  the 
source  of  user  inputs  identified  at  ClCl).  Messages  for 
users  submitting  inputs  from  a terminal  will  be  delivered 
by  (.4)  to  the  user's  terminal.  Messages  for  users  sub- 
mitting inputs  from  a card  reader  or  other  such  device 
will  be  delivered  by  (3)  to  the  on-line  printer. 
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"Sufamtt  User  Request"  (_C2 control s the  modification 
and  use  of  SOFTSAS  data.  Since  restrictions  can  be  placed 
on  the  types  of  requests  users  are  authorized  to  submit, 
"Submit  User  Name"  (_C1)  identifies  each  user  to  the  system. 

Two  types  of  output  will  be  delivered  to  the  user: 
formal  reports  and  messages.  All  formal  reports  are 
written  to  the  on-line  printer  (01).  However,  messages 
are  only  delivered  to  the  printer  (02)  when  SOFTSAS  is 
executing  in  the  batch  mode.  When  executing  interactively, 
that  is,  when  a user  is  submitting  inputs  from  a terminal, 
SOFTSAS  will  deliver  all  messages  to  the  user's  terminal 
(03). 
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Determine  Report 
Requirements/ 


Software  Status  Accounting  System  Data 


DO  Text 

"System  Data"  111  is  information  that  is  "hard-coded" 
into  the  SOFTSAS  software.  It  provides  formatting  and 
data  retrieval  requirements  (1011  for  formal  reports  as 
needed  and  supplies  the  appropriate  SOFTSAS  request  vali- 
dation criteria  (102)  for  the  user  identified  by  (1C1). 

"Requests"  (2)  consists  of  user  requests  and  database 
requests.  Activity  (211)  supplies  user  requests  which  are 
echoed  back  to  the  user  by  (204),  and  are  checked  against 
validation  criteria  obtained  by  (2C1).  Activity  (202) 
processes  database  requests  and  returns  the  status  of  the 
outcome.  For  data  update  requests,  (203)  provides  the  new 
data  to  be  stored  in  the  database.  For  data  retrieval, 
requests  and  depending  upon  the  type  of  request,  (201) 
uses  the  information  supplied  in  the  request  or  supplied 
by  (2C2)  to  determine  output  formatting  requirements.  Any 
messages  for  the  user  caused  by  request  processing  are 
generated  by  (204). 

The  "Status  Accounting  Database"  (3)  consists  of  a 
directory  of  data  descriptions,  a dictionary  of  data 
storage  locations,  and  the  status  accounting  data  itself. 
The  processing  of  database  requests  ( 3 C 1 ) controls  whether 
data  is  to  be  stored  (311)  or  retrieved  (301). 

"User  Outputs"  (4)  consist  of  reports  and  messages. 
Data  obtained  by  C4I1)  are  formatted  for  output  as  deter- 
mined by  (4C1),  while  messages  generated  by  C4I2)  are  out- 
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putted  without  change.  All  reports  are  delivered  to  the 
on-line  printer  C4011.  Messages  can  be  delivered  to  the 
user's  terminal  (_4Q3)  or  the  on-line  printer  (402). 


Submit 

-User 


Figure  3-12  System  Data 


D1  Text 


"User  Authorizations"  Cl  1 is  a list  of  the  types  of 
request  that  each  user  is  authorized  to  submit  f4Ql). 
"Request  Syntax"  (_2)  are  the  legal  syntax  for  each  type  of 
SOFTSAS  request  (2Q1).  Together,  (10L11  and  C201)  deliver 
validation  criteria  for  checking  the  input  of  the  user 
identified  by  ClCl } . 

"Report  Definitions"  (.3)  consist  of  data  and  format- 
ting requirements  for  SOFTSAS  formal  reports.  Activity 
(3C1)  names  those  requirements  to  be  delivered  by  (301)  for 
processing  of  PRODUCE  requests. 

The  above  data  (1,  2,  3)  are  a predefined  part  of 
SOFTSAS. 
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Give  Request  Typo 


Figure  3-13  Requests 


Figure  3-14  Status  Accounting  Database 


D3  Text 


All  activity  on  the  database  Cl.  2,  31  result  from 
either  database  maintenance  or  database  use  requests.  Data- 
base maintenance  requests  are  processed  for  programs  run 
by  the  Database  Administrator.  These  requests  direct  that 
the  dictionary  Cl  1 be  created  or  modified  (112),  that  an 
old  database  replace  the  current  one  (111,  311),  or  that  a 
copy  of  the  database  he  saved  (101,  301).  Database  use 
requests  are  processed  for  user  application  programs. 

These  requests  control  adding,  modifying,  deleting,  and  re- 
trieving user  data  (312,  301)  and  retrieving  data  descrip- 
tions (102). 

The  "Database  Director"  (2)  is  modified  by  (212)  when 
processing  ADD-NEW  and  DELETE  requests  (2C2)  and  their 
values  are  obtained  by  (211).  The  directory  is  used  by 
(201)  to  locate  data  when  processing  a FIND  request  (2C2). 

Data  storage  locations  and  data  formats  obtained  by 
(3C1)  and  (3C2),  respectively,  control  (312)  and  (302)  when 
processing  ADD-NEW,  DELETE,  UPDATE,  and  GET-DATA  requests 
(3C3). 

"Processing  Status"  (4)  is  an  indicator  of  the  outcome 
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status  of  a request.  The  status  is  recorded  (411)  for- 
checking  (401)  after  completion  of  each  request. 

"After-images"  (5)  are  modifications  to  the  database 
that  are  recorded  (511)  and  saved  (501)  to  aid  in  database 
recovery  (112,  312)  after  a failure. 
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D4  Text 

"Retrieved  Data"  (1)  ts  obtained  Clll)  from  the  data- 
base and  is  used  Q01.  1Q2)  to  build  reports  and  responses 
to  ad  hoc  queries  for  data  according  to  formatting  require- 
ments specified  by  (1C1).  "Reports"  (2)  are  constructed 
(211)  and  output  to  the  on-line  printer  (201).  "Messages" 

(3)  consist  of  query  responses,  user  prompts,  error  notifi 
cations,  and  copies  of  the  input  requests.  Once  con- 
structed (311,  312),  these  messages  are  output  (301)  to  the 
user.  They  are  written  to  the  user's  terminal  (02)  if 
(3C1)  determines  the  inputs  were  received  from  a terminal. 

Otherwise,  they  are  written  to  the  on-line  printer  (03). 


This  chapter  presented  the  formal  functional  specifica- 


tion for  SOFTSAS  in  the  form  of  SADT  activity  and  data 
models.  These  models  were  used  to  design  a structure  for 
the  software  which  will  satisfy  the  status  accounting  re- 
quirements for  software  configuration  management.  The 
structure  that  was  designed  is  presented  in  Chapter  IV. 
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IV  Software  Design  Specification 
Introduction 

The  third  stage  in  the  software  development  life- 
cycle  consists  of  deriving  an  internal  structural  design 
for  the  software  to  satisfy  the  requirements  specified 
during  stage  two.  This  design  provides  the  missing  link 
between  the  external  specifications  of  the  system  and  the 
internal  algorithms  which  comprise  individual  program 
modules.  It  identifies  the  major  components  of  th&  system, 
the  functions  that  they  perform,  and  the  interfaces  between 
them.  The  sections  in  this  chapter  present  an  overview  of 
some  fundamental  software  design  considerations,  a prelimi- 
nary design  specification  for  SOFTSAS,  and  a brief  summary 
of  observations  that  were  made  while  developing  the  design. 

Software  Design  Considerations 

Design  plays  an  important  role  in  the  development  of 
software.  Thayer  et  al  (Ref  38:4,160-163)  determined  that, 
in  one  software  project,  28.7%  of  the  errors  that  were  intro- 
duced as  a result  of  coding  changes  and  detected  during  sub- 
system/system testing  could  have  been  prevented  had  some 
sort  of  design' standard  been  used.  In  other  studies, 

Boehm  (Ref  9)  discovered  that  64%  of  detected  errors  were 
due  to  design,  and,  in  the  NASA  Apollo  project,  Hamilton  and 
Zeldin  (Ref  15)  found  that  73%  of  all  errors  were  design 
errors.  Moreover,  Lehman  (Ref  18)  surveyed  major  aerospace 
firms  that  were  managing  57  software  projects  and  found 
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that,  on  the  average,  44%  of  all  production  time  was  spent 
on  requirements  analysis  and  design  activities.  This  Is 
consistent  with,  the  report  by  Weiss  (.Ref  39:26)  which  sug- 
gests that  40%  of  software  development  time  be  allocated 
to  design. 

The  primary  goal  of  software  design  is  to  develop  a 
program  structure  that  satisfies  a set  of  requirements  and 
constraints  at  the  minimum  life-cycle  cost.  Life-cycle 
costs  incude  the  costs  of  developing,  operating,  and  main- 
taining the  system.  Constantine  (Ref  11:9-12)  suggests 
that  these  costs  are  a function  of  a program's  quality  as 
measured  in  terms  of  its  efficiency,  reliability,  maintain- 
ability, modifiability,  generality,  flexibility,  and 
utility.  Several  "structural"  approaches,  or  methodo- 
logies, for  software  design  exist  which  show  how  to  develop 
and  portray  "good  quality"  designs.  In  particular, 
Constantine's  "Structured  Design"  technique  (Ref  11)  was 
used  in  this  thesis. 

The  Structured  Design  technique  recognizes  that  develop 
ment  of  software  Is  a non-trivlal  problem  and  that  humans 
do  not  deal  well  with  complexity.  It  requires  Iterative 
decompositions  of  software  tasks  into  smaller  sub-tasks 
(sometimes  called  "stepwise  refinement")  until  the  sub- 
tasks are  manageably  small  and  solvable  separately.  More- 
over, it  recommends  that  each  sub-task  be  composed  of  a 
single,  well-defined  function  that  is  performed  by  one  pro- 
gram "module".  As  long  as  the  modules  are  relatively 
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together  tend  to  be  more  effectively  modular  and  tend  to 
minimize  intermodular  coupling.  Constantine  (.Ref  11:96-126) 
describes  seven  levels  of  cohesion  differentiated  by  seven 
associative  principles. 

In  addition  to  these  measures  of  program  quality, 
Constantine  also  describes  several  design  heuristics 
which.  If  properly  used,  may  improve  systems  structures. 

These  heuristics  include  module  size,  span  of  control, 
fan-in,  and  scope  of  effect/scope  of  control. 

Structure  Charts 

This  section  contains  a design  specification  for  SOFTSAS 
that  was  derived  using  the  Structured  Design  strategies  of 
"transform  analysis"  and  "transaction  analysis"  (Ref  11:171- 
222).  The  specification  consists  of  graphical  representa- 
tions (structure  charts)  of  the  program's  structural  organi- 
zation, tables  of  module  Interface  definitions,  and  sup- 
porting text  to  describe  the  function  of  each  module. 

These  were  derived  by  conceptualizing  the  formal  functional 
specifications  in  terms  of  data  flows  to  which  Constantine's 
design  guidelines  were  systematically  applied.  An  explana- 
tion of  the  symbols  used  in  the  structure  charts  Is  con- 
tained in  Appendix  B. 
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Run  SOFTSAS.  This  module  Is  the  program  supervisor. 

It  controls  the  reading  and  processing  of  user  requests  as 
well  as  the  writing  of  user  reports  and  messages.  The 
module  determines  the  operating  mode  of  the  program  which. 

In  turn,  determines  If  messages  are  to  be  accumulated  or 
delivered  Immediately  to  a terminal.  In  addition,  the 
operating  mode  dictates  whether  or  not  certain  "prompt" 
messages  will  be  generated.  The  module  alternately  Invokes 
'Get  Converted  Request'  to  obtain  a user  request  (In  Inter- 
nal form)  and  'Satisfy  Request'  to  process  It.  This 
sequence  is  Iterated  either  until  an  'End'  request  Is  en- 
countered or  until  a non-recoverabl e error  Is  detected  dur- 
ing batch  processing.  In  either  case,  the  module  calls  on 
'Satisfy  Request'  to  close  any  database  realms  that  may  still 
be  open,  and  then  Invokes  'Put  Outputs'  to  deliver  all  accu- 
mulated reports  and  messages. 

Determine  Operating  Mode.  This  module  determines 
whether  SOFTSAS  Is  executing  In  the  batch  or  Interactive 
mode.  There  are  several  ways  In  which  this  can  be  accom- 
plished, depending  upon  the  user  support  provided  by  the 
operating  system.  For  example,  the  module  could  query  the 
file  control  block  of  the  Input  file  to  ascertain  the  type 
of  device  being  used.  Or,  an  unused  switch  In  the  program 
status  word  could  be  set  by  the  user  to  signal  the  Intended 
mode  of  operation.  Moreover,  a simple  questlon-and-answer 
sequence  between  the  user  and  the  module  could  provide  the 
Information . 
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Get  Converted  Request.  This  module  supervises  the 
acquisition  of  a single,  valid  user  Input  request  and  the 
transformation  of  that  request  from  Its  English-like  repre- 
sentation to  a more  usable  tabular  form.  A request  Is  valid 
if  it  conforms  to  the  syntactic  rules  established  for  that 
type  of  request.  A valid  request  consists  of  a command.  Its 
required  and  optional  parameters,  and  an  end-of-request 
(EOR)  symbol.  The  command  must  precede  the  rest  of  the  re- 
quest, and  the  parameters  may  span  more  than  one  logical 
record.  Each  parameter  clause  that  can  appear  In  a request 
has  a corresponding  Internal  table  (command,  search,  sort, 
or  update)  that  Is  constructed  when  the  clause  appears  In 
the  request.  These  tables  are  used  to  process  the  request. 

Satisfy  Request.  This  module  Is  a transaction  center 
which  dispatches  the  internal  request  tables  to  a subordi- 
nate request  handler  module,  based  upon  the  type  of  request 
to  be  processed.  The  module  performs  a coordinating  func- 
tion, relaying  processing  and  status  Information  (via  "error 
flag")  between  the  'SOFTSAS  Executive'  module  and  the  request 
processor  modules.  It  also  monitors  realms  In  use. 

Put  Outputs.  This  module  supervises  the  delivery  of 
any  accumulated  messages  and  reports  to  an  on-line  printer 
just  prior  to  job  termination.  Output  line  Images  are 
collected  In  two  files  by  SOFTSAS  request  handlers.  One 
file  Is  used  to  hold  the  reports;  the  other  Is  used  to  hold 
messages,  except  when  SOFTSAS  Is  executing  In  the  Inter- 
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Figure  4-2  GET  CONVERTED  REQUEST  Branch 


6,  14  File  name 


User  input  line 
operating  mode 


Table  HI 


Interfaces  for  GET  CONVERTED  REQUEST  Branch 


OUTPUT 


Request  type,  internal  request 
tables,  error  flag 


Operating  mode 


Request  type,  parameter 
clauses,  error  flag 


Internal  request  tables 


4 Parameter  clauses 


5,  13  File  name,  output 
line,  line  size 


Error  fla 


Input  line,  line  size, 
error  flag 


Request  type,  parameter 
clauses,  error  flag 


8 Request  type 


Error  fla 


9 Command  clause 


Command  table 


10  Search  clause 


Search  tables 


Sort  table 


12  Update  Clause 


Update  table 


User  name 


16  Search  clause 


Modified  search  clause, 
criteria  table 


17  Modified  search  clause 


Logic  table 


o 
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Get  Converted  Request.  This  nodule  supervises  the 
acquisition  of  a single,  valid  user  input  request  and  the 
transformation  of  that  request  from  its  English-like  repre- 
sentation to  a more  usable  tabular  form.  A request  is  valid 
if  it  conforms  to  the  syntactic  rules  established  for  that 
type  of  request.  A valid  request  consists  of  a command,  its 
required  and  optional  parameters,  and  an  end-of-request  (EOR) 
symbol.  The  command  must  precede  the  rest  of  the  request, 
and  the  parameters  may  span  more  than  one  logical  record. 

Each  parameter  clause  that  can  appear  in  a request  has  a 
corresponding  internal  table  (command,  search,  sort,  or  up- 
date) that  is  constructed  when  the  clause  appears  in  the 
request.  These  tables  are  used  to  process  the  request. 

Get  Analyzed  Request.  This  module  controls  the  input 
and  syntactic  analysis  of  a user  request.  It  first  writes 
a message  to  advise  the  user  that  SOFTSAS  is  ready  to  pro- 
cess a request.  It  then  reads  a logical  record  from  input, 
echoes  it  to  the  message  file,  and  calls  on  'Parse  Input 
Line'  to  identify  and  validate  the  request's  component 
parts.  Valid  requests  are  accepted  and  are  passed  to  the 
superordinate  module  for  processing.  Invalid  requests  are 
rejected,  and  an  error  message  is  written  to  the  message 
file.  User  errors  that  are  detected  by  this  module  are  non- 
fatal  when  SOFTSAS  is  executing  in  the  interactive  mode; 
the  module  will  just  prompt  the  user  for  another  request. 

In  the  batch  mode,  however,  the  module  sets  an  error  indica- 
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tor  for  Its  superordinate  which  ultimately  results  In  pre- 
mature joh  termination. 

Convert  Request.  Upon  accepting  parameter  clauses  as 
input,  this  module  "zeroes  out"  all  Internal  request  tables 
and  dispatches  to  the  appropriate  subordinate  modules  to 
convert  the  clauses  into  their  corresponding  tabular  forms. 

A command  table  will  be  used  to  hold  the  report  names  from 
a PRODUCE  request,  the  realm  names  from  OPEN  and  CLOSE  re- 
quests, and  all  of  the  parameters  from  a DESCRIBE  request. 
Search  tables  will  hold  any  relational  expressions  and 
logical  operators  found  in  a WHERE  clause  and  tha  names  of 
the  record  (type)  to  be  accessed,  when  applicable.  A sort 
table  will  hold  the  field  names  and  qualifiers  found  in  a 
SORT  clause.  An  update  table  will  hold  the  equivalence 
expressions  (field  names  and  values)  found  in  a SETTING 
clause. 

Parse  Input  Line.  This  module  contains  the  validation 
criteria  for  each  request.  It  accepts  and  lexically 
analyzes  a user  input  line.  For  valid  requests,  it  returns 
the  type  of  request  and  the  request  parameters  to  the  super- 
ordinate. If  the  line  does  not  contain  an  end-of-request 
mark,  the  module  obtains  another  logical  record  from  input. 
If  an  EOR  mark  is  encountered  when  required  parameters  are 
missing  and  SOFTSAS  is  executing  In  the  interactive  mode, 
the  module  will  prompt  the  user  for  the  required  input 
( parameter  and  then  attempt  to  read  it.  Tf  the  attempt 
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fails  or  if  SOFTSAS  is  executing  in  the  batch  mode,  the 
module  writes  an  error  message  to  the  message  file  and 
sets  an  error  indicator  for  its  superordinate. 

Check  User  Authorization.  This  module  Insures  that  the 
user  of  the  program  is  authorized  to  submit  the  request  cur- 
rently being  analyzed.  It  invokes  a system-supplied  rou- 
tine to  obtain  the  name  of  the  user  from  the  operating 
system. 

Build  Command  Table,  Build  Search  Tables,  Build  Sort 
Table,  Build  Update  Table.  These  modules  are  called  to  con- 
struct their  respective  tables,  given  their  corresponding 
parameter  clauses  as  input.  In  particular,  'Build  Search 
Tables'  supervises  the  construction  of  a criteria  table  and 
a logic  table.  These  tables  are  used  to  "find"  the 
identifiers  of  database  record  occurrences  to  be  accessed. 
Each  entry  in  the  criteria  table  will  completely  describe  a 
relational  expression  that  appears  in  a WHERE  clause.  The 
logic  table  will  describe  logical  operations  to  be  performed 
on  the  lists  of  identifiers  obtained  using  the  relational 
criteria. 

Get  User-ID.  This  is  a system-supplied  interface 


module  which  obtains  from  the  operating  system  the  name  of 
the  user  executing  the  program. 


Build  Criteria  Table.  This  module  scans  a WHERE 
clause  and  creates  a table  entry  for  each  relational  expres- 


U 

sion  It  encounters.  A pointer  to  that  entry  Is  used  to 
replace  the  expression  in  the  original  clause.  The  modified 
clause  Is  returned  to  the  superordinate  with  the  criteria 
table  entries. 

Build  Logic  Table.  This  module  transforms  the  modified 
WHERE  clause  to  its  postfix  (reverse  Polish  notation)  repre- 
sentation, stacking  the  logical  operators  and  operands  In 
the  logic  table.  The  entries  of  the  table  will  unambiguously 
describe  the  logical  operations  - intersection  and  union  - 
to  be  performed  on  lists  of  record  Identifiers,  as  well  as 
the  order  in  which  the  operations  will  be  performed. 
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1 Requast  type.  Internal 
request  tables 

2 Command  table,  sort  table 
search  tables 

3 Command  table,  search 
tabl es 

4 Command  table 

5 Criteria  table,  update 
table 

6 Update  table,  search 
tables 

7 Search  tables 

8 Command  table,  update 
tabl  e 


Error  flag 

Error  flag 

Error  flag 

Error  flag 
Error  flag 

Error  flag 

Error  flag 

Error  flag,  opened  realm  name 


9 Command  table 


Error  flag,  closed  realm  name 


Satisfy  Request.  This  module  is  a transaction  center 
which  dispatches  the  internal  request  tables  to  a subordi- 
nate request  handler  module,  based  upon  the  type  of  request 
to  be  processed.  The  module  performs  a coordinating  func- 
tion, relaying  processing  and  status  information  (via  "error 
flag")  between  the  'SOFTSAS  Executive'  module  and  the  request 
processor  modules.  It  also  monitors  realms  in  use. 

Do  PRINT  Request.  This  module  supervises  the  retrieval 
of  status  accounting  data  from  the  database  and  the  format- 
ting of  this  data  for  printing.  The  module  Invokes  'Get 
Approved  Identifiers'  to  determine  the  identity  of  those 
record  occurrences  that  satisfy  the  search  table  criteria. 

In  the  Interactive  mode  only,  the  user  is  Informed  of  the 

♦ 

number  of  occurrences  found,  and  his  approval  must  be 
obtained  to  continue  processing  the  request.  The  approved 
identifiers  are  then  passed  to  the  "Construct  PRINT  Response' 
module  together  with  the  names  of  the  fields  to  be  accessed 
and  the  criteria  tn  be  used  to  sort  the  retrieved  data  prior 
to  printing  It.  The  resultant  query  response  is  then 
obtained  and  written  to  the  message  file.  Finally,  a mes- 
sage is  written  to  the  message  file  to  Indicate  whether 
or  not  the  request  was  successfully  accomplished. 

Do  PRODUCE  Request.  This  module  supervises  the  con- 
struction of  one  or  more  formal  reqports  requested  by  the 
user.  Each  report  can  contain  data  for  more  than  one  CPCI. 
The  module  first  identifies  those  CPCIs  which  are  to  be 
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reported  and  then  builds  the  named  reports.  Each  report  Is 
written  to  the  report  file  as  It  Is  being  constructed,  and 
a nonrecoverable  error  terminates  processing  of  the  request 
when  It  occurs.  A message  Is  written  Indicating  the  out- 
come of  the  request. 


■ 


Do  DESCRIBE  Request.  This  module  Is  a transaction 
center  which  handles  requests  for  Information  about  the 
logical  structure  of  the  database.  It  determines  which  of 
the  six  possible  types  of  DESCRIBE  request  was  submitted, 
dispatches  to  the  appropriate  transaction  level  module  to 
construct  a response  to  the  request,  and  writes  the  con- 
structed response  to  the  message  file.  In  addition.  It 
writes  a message  to  the  message  file  to  indicate  whether  or 
not  the  request  was  successfully  accomplished. 


| 


Do  CREATE  Request.  This  module  handles  a user  request 
to  add  a new  occurrence  to  a database  record,  and  it  writes 
a message  to  the  message  file  to  inform  the  user  of  the  out- 
come status  of  his  request.  If  the  request  Is  processed 
successfully,  and  If  it  reflects  either  a new  ECP  having 
been  submitted  or  a new  document  or  change  notice  have  been 
issued,  the  module  Invokes  'Add  Active-Item  Occurrence'  to 
record  the  event. 


Do  MODIFY  Request.  This  module  handles  a user  request 
to  alter  the  contents  of  one  or  more  database  record  occur- 
rences. It  Invokes  subordinate  modules  to  Identify  the 
occurrences  that  satisfy  the  search  criteria  and  to  perform 
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the  database  update.  However,  prior  to  making  any  changes 
In  the  Interactive  mode,  the  module  warns  the  user  with  a 
message  which  states  how  many  qualified  record  occurrences 
were  located  and  requests  his  approval  to  continue  proces- 
sing the  request.  Changing  certain  monitored  fields  in  the 
database  (such  as  ECP  priority  or  status!  requires  that  an 
active-item  record  occurrence  be  added  to  the  database  to 
register  the  event.  After  processing  the  user's  request, 
the  module  reports  the  outcome  status  to  the  user  and  sets 
an  error  Indicator  for  its  superordinate. 

Do  DELETE  Request.  This  module  obtains  the  Identifiers 
of  record  occurrences  to  be  deleted  and  Invokes  'Remove 
Record  Occurrences'  to  delete  them,  and  all  pointers  to 
them,  from  the  database.  Prior  to  making  the  deletions  in 
the  interactive  mode,  the  module  warns  the  user  with  a mes- 
sage which  indicates  how  many  record  occurrences  were  found 
that  satisfy  the  search  criteria.  The  message  also  re- 
quests the  user's  approval  to  perform  the  deletions. 
Afterwards,  the  module  writes  a message  to  the  message  file 
to  inform  the  user  about  the  outcome  status  of  his  request. 

Do  OPEN*  Request.  This  module  handles  a user  request 
to  prepare  a database  realm  for  processing.  It  extracts 
the  user  Identifier  and  realm  access  mode  from  the  update 
table  and  Invokes  the  system-supplied  DBMS  Interface  routine 
'Open'.  If  the  request  Is  successfully  accomplished,  the 
module  transmits  the  name  of  the  opened  realm  to  the  SOFTSAS 
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executive.  The  module  will  set  an  error  Indicator  for  Its 
superordinate  and  will  notify  the  user  about  the  outcome 
of  his  request. 

Do  CLOSE  Request.  This  module  handles  a user  request 
to  discontinue  processing  of  a database  realm.  It  Invokes 
a DBMS  Interface  routine  to  de-allocate  the  realm,  checks 
the  DBMS  status  return  code,  notifies  the  user  about  the 
outcome  of  the  request,  and  sets  an  error  Indicator  for 
Its  superordinate.  It  also  returns  the  name  of  the  realm 
that  was  closed. 


Request 


DO  PRINT  REQUEST  Branch 


Table  V 


Interfaces  for  DO  PRINT  REQUEST  Branch 


INPUT 


OUTPUT 


1 

Command  table,  sort  table, 
search  tables 

Error  flag 

2 

Search  tables 

Approved  record  Identifiers 
record  name,  error  flag 

3 

Command  table,  sort  table, 
record  tdentlf i lers , re- 
cord name 

Edited  PRINT  response, 
error  flag 

4 

File  name,  output  line, 
line  size 

Error  flag 

5 

Record  name,  record 
Identifiers,  field 
names 

Retrieved  data,  error  flag 

6,7 

Retrieved  data,  sort 
criteria 

Sorted  data,  error  flag 

8 

Sorted  data,  field  names 

Edited  PRINT  response 

9 

Operating  mode 

10 

Item  name,  action  code 

Data  Item  description, 
error  flag 
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Do  PRINT  Request.  This  module  supervises  the  retrieval 
of  status  accounting  data  from  the  database  and  the  format- 
ting of  this  data  for  printing.  The  module  Invokes  'Get 
Approved  Identifiers'  to  determine  the  Identity  of  those 
record  occurrences  that  satisfy  the  search  table  criteria. 

In  the  Interactive  mode  only,  the  user  Is  Informed  of  the 
number  of  occurrences  found,  and  his  approval  must  be  ob- 
tained to  continue  processing  the  request.  The  approved 
Identifiers  are  then  passed  to  the  "Construct  PRINT  Re- 
sponse' module  together  with  the  names  of  the  fields  to  be 
accessed  and  the  criteria  to  be  used  to  sort  the  retrieved 
data  prior  to  printing  It.  The  resultant  query  response 
Is  then  obtained  and  written  to  the  message  file.  Finally, 
a message  Is  written  to  the  message  file  to  Indicate 
whether  or  not  the  request  was  successfully  accomplished. 

Construct  PRINT  Response.  This  module  supervises  the 
construction  of  a database  query  response.  It  obtains  items 
of  data  from  each  qualified  record  occurrence  and.  If  no 
error  occurs,  orders  this  data  as  specified  In  the  sort 
table.  The  sorted  data  Is  then  edited  for  output  and  Is 
passed  to  the  superordinate  module. 

Sort.  This  Is  a system-supplied  routine  which  sorts 
tabled  data  based  upon  specific  criteria.  The  criteria 
consists  of  a prioritized  list  of  field  names  on  which  to 
sort  (keys)  and  a sort  mode  (.ascending  or  descending)  for 
each  of  the  fields. 
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Edit  Response.  This  module  accepts  sorted,  tabled 
data  and  edits  each  entry  for  output.  It  obtains  the  pro- 
gram's operating  mode  to  determine  the  length  for  an  output 
line,  and  It  obtains  field  descriptions  to  determine  the 
format  In  which  to  present  each  item  of  data.  The  Items  of 
data  will  be  presented  In  a line  in  the  same  order  as  their 
corresponding  fields  were  named  In  the  user  request. 


Figure  4-5  DO  PRODUCE  REQUEST  Branch 


Interfaces  for  DO  PRODUCE  REQUEST  Branch 


OUTPUT 


INPUT 


1 Command  table,  search 
tabl es 


Error  fla 


CPCI  numbers,  CP C I names 
error  flag 


2 Search  tables 


3,4,5  CPCI  numbers,  CPCI 
names 


Error  fla 


Record  name,  record  identl 
fiers,  error  flag 


CPCI  numbers,  CPCI  names 
error  flag 


Record  name,  record 
identifiers,  field 
names 


I 


Do  PRODUCE  Request.  This  module  supervises  the  con- 
struction of  one  or  more  formal  reports  requested  by  the 
user.  Each  report  can  contain  data  for  more  than  one  CPCI. 
The  module  first  identifies  those  CPCIs  which  are  to  be  re- 
ported and  then  builds  the  named  reports.  Each  report  is 
written  to  the  report  file  as  It  is  being  constructed,  and 
a nonrecoverable  error  terminates  processing  of  the  request 
when  it  occurs.  A message  is  written  Indicating  the  out- 
come of  the  request. 

Identify  CPCIs.  This  module  obtains  the  numbers  and 
names  of  the  CPCIs  to  be  reported.  It  first  validates  the 
contents  of  the  criteria  table,  and  generates  an  error 
message  if  the  table  contains  any  field  names  other  than 
those  of  the  primary  key  for  CPCI  records.  It  then  obtains 
the  identifiers  of  record  occurrences  that  satisfy  the 
search  criteria,  using  them  to  retrieve  the  numbers  and 
names  of  the  CPCIs  to  be  reported. 

Build  Configuration  Index.  This  module  supervises 
the  construction  of  the  Configuration  Index  for  the  named 
CPCIs.  It  invokes  subordinate  modules  to  construct  one 
title  page  followed  by  six  report  sections  for  each  CPCI 
to  be  reported.  Detection  of  an  error  by  any  of  the 
subordinate  modules  terminates  processing  of  the  request 
and  results  in  this  module  and,  in  turn,  this  module's 
superordinate  ttelng  notified. 


Build  Computer  Program  Change  Report.  This  module 
supervises  the  construction  of  the  Computer  Program  Change 
Report  CCPCR)  for  the  named  CPCIs.  It  invokes  subordinate 
modules  to  construct  one  title  page  followed  by  three  sec- 
tions (change  history,  change  status,  and  red  flag  and 
activity)  for  each  CPCI  to  be  reported.  Detection  of  an 
error  by  any  of  the  subordinate  modules  terminates  pro- 
cessing of  the  request  and  results  in  this  module  and.  In 
turn,  this  module's  superordinate  being  notified. 

Build  Software  Tree.  This  module  supervises  the  con- 
struction of  a family  tree  for  the  modules  of  each  named 
CPCI.  The  tree  Is  a hierarchical  data  structure  which  de- 
scribes the  functional  organization  of  the  CPCI's  modules. 
Each  module  Is  assigned  a unique  seven-character  tree  code 
by  the  user.  This  code  is  used  to  identify  the  module  and 
the  functions  that  It  supports  within  the  CPCI.  'Build 
Software  Tree'  calls  subordinate  modules  to  construct  a 
title  page,  a hierarchical  breakdown  of  the  function  of  the 
CPCI's  components,  and  a list  of  the  modules  (grouped  by 
function)  which  comprise  the  CPCI. 


BUILD  CONFIGURATION  INDEX  Branch 


Table  VII 


Interfaces  for  BUILD  CONFIGURATION  INDEX  Branch 


INPUT 

I,  2 CPCI  numbers, 

CPCI  names 

3,  4,  5,  6,  7,  8 CPCI 
number,  CPCI  name 

9,  12,  15,  18,  21,  24,  27 

Search  tables 

10,  13,  16,  19,  22,  25,  28 

Record  name,  record 
Identifiers,  field 
names 

II,  14,  17,  20,  23,  26,  29 

File  name,  output  line, 
line  size 


OUTPUT 
Error  flag 


Error  f 1 a< 


Record  name,  record  Identi- 
fiers, error  flag 

Retrieved  data,  error  flag 


Error  fla.< 
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Build  Configuration  Index.  This  module  supervises 
the  construction  of  the  Configuration  Index  for  the  named 
CPCIs.  It  Invokes  subordinate  modules  to  construct  one 
title  page  followed  by  six  report  sections  for  each  CPCI 
to  be  reported.  Detection  of  an  error  by  any  of  the  sub- 
ordinate modules  terminates  processing  of  the  request  and 
results  In  this  module  and,  in  turn,  this  module's  super- 
ordinate being  notified. 

Build  Index  Title  Page.  This  module  Is  Invoked  once 
during  the  construction  of  the  Index.  The  module  locates 
and  retrieves  document  Identification  data  for  the  Index 
such  as  Issuing  agency,  document  number,  and  contract  num- 
ber. It  then  edits  this  data  and  writes  output  lines  to  the 
report  file. 

Build  Section  I,...,  Build  Section  VI.  These  modules 
are  Invoked  once  for  each  CPCI.  They  produce  formatted 
status  accounting  data  about  each  of  six  types  of  maintain- 
able documents  (development  specification,  produce  specifi- 
cation, test  plans/reports,  handbooks,  manuals,  and  version 
description  documents).  Each  section  will  consist  of  Infor- 
mation Identjfying  the  type  of  document  being  reported,  the 
current  configuration  of  each  of  the  documents  of  that  type, 
and  any  approved  engineering  changes  that  will  affect  the 
documents  In  the  future. 
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Table  VIII 

Interfaces  for  BUILD  COMPUTER  PROGRAM  CHANGE  REPORT  Branch 


INPUT 


OUTPUT 


1,  2 CPCI  numbers,  CPCI 
names 


Error  fla 


3,  4,  5 CPCI  number,  CPCI  Error  fla 
name 


12,  24,  26,  28,  30,  32  Record  name,  record  Identl 
Search  tables  flers,  error  flag 


29,  31,  33  Retrieved  data,  error  fla 
record 
field  names 


Record  name 
identifiers 


8,  11,  14  File  name 
line,  line  size 


Error  fla 


15  CPCI  number 


Unsorted 
error  fla 


16  CPCI  number 


Unsorted 
error  fla 


17  Unsorted  "red  fl 
"activity"  data 


and  Sorted  "red  fla 
"activity"  data 


Current  date 


20  CPCI  number 


"Red  flag"  ECP  data 
error  flag 


21  CPCI  number 


"Red  flag"  document  data 
error  flag 


22  CPCI  number 


change  notice 


error  fla 


"Active"  Item  Identifiers 
error  flag 


Build  Computer  Program  Change  Report.  This  module 
supervises  the  construction  of  the  Computer  Program  Change 
Report  (.CPCR)  for  the  named  CPCIs.  It  Invokes  subordinate 
modules  to  construct  one  title  page  followed  by  three  sec- 
tions Cchange  history,  change  status,  and  red  flag  and 
activity)  for  each  CPCI  to  be  reported.  Detection  of  an 
error  by  any  of  the  subordinate  modules  terminates  pro- 
cessing of  the  request  and  results  in  this  module  and.  In 
turn,  this  module's  superordinate  being  notified. 


Build  CPCR  Title  Page.  This  module  is  Invoked  once 
during  the  construction  of  the  CPCR.  It  locates  and 
retrieves  document  Identification  data  for  the  CPCR  such  as 
issuing  agency,  document  number,  and  contract  number.  It 
then  edits  this  data  and  writes  output  lines  to  the  report 
file. 

Build  Change  History.  This  module  finds  all  the  ECP 
records  In  the  database  that  have  affected,  or  will  affect, 
the  named  CPCI.  Information  such  as  the  number  and  title 
of  the  ECPs,  their  current  status  and  date  of  status,  and 
the  contract  numbers  under  which  they  were  approved  is  ob- 
tained and  Is  written  to  the  report  file. 

Build  Change  Status.  This  module  finds  all  the  cur- 
rently active  ECPs  In  the  database  that  affect  the  named 
CPCI.  Active  ECPs  are  those  which  have  been  approved  but 
have  not  heen  completed.  Extensive  Information  concerning 
the  Identification  and  the  development  schedule  of  each 
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qualified  engineering  change,  together  with  lists  of 
modules,  documents,  hardware,  and  other  CPCIs  affected  by 


the  change,  are  retrieved  from  the  database  and  written  to 


the  report  file. 


Build  Red  Flag  and  Activity.  This  module  constructs 


the  third  section  of  the  CPCR  for  each  named  CPCI.  A 


table  of  data  for  "red  flag"  and  "active"  Items  is  formed, 


sorted  by  priority,  edited  for  output,  and  written. to  the 


report  file.  A red  flag  Item  Is  an  ECP,  document,  or  change 


notice  that  has  missed  a suspense  date,  will  miss  a suspense 


date  within  3Q  days,  or  has  not  had  a suspense  date  sche- 


duled for  a milestone.  An  active  Item  is  one  that  has 


undergone  certain  specific  changes  within  the  current  re- 


porting period. 


Get  Red  Flag  Data.  This  module  supervises  the  identi- 


fication of  red  flag  Items  and  the  retrieval  of  red  flag 


data  for  reporting.  It  Invokes  subordinates  to  compare  the 
current  date  against  scheduled  (or  non-schedul ed ) ECP,  docu- 


ment, and  change  notice  milestone  dates.  The  number,  title. 


priority  and  remarks  of  each  red  flag  item  is  obtained  and 


passed  to  th.e  module's  superordinate. 


Get  "Active-item"  Data.  This  module  invokes  a subor- 


dinate to  find  data  items  that  have  been  "active"  during 


the  reporting  period.  It  then  retrieves  the  number,  title, 
priority  and  remarks  of  each  found  item  and  passes  this 


Information  to  Its  superordinate  for  reporting. 
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Get-Date.  This  Is  a system-supplied  module  which  pro 
vldes  the  current  date  from  the  system  clock. 

Obtain  Red  Flag  ECP  Data,  Obtain  Red  Flag  Document 


Data,  Obtain  Red  Flag  Change  Notice  Data.  These  modules 
search  the  database  for  "red  flag"  ECPs,  documents,  and 
change  notices  respectively.  The  names,  numbers  and 
priorities  of  all  "red  flag"  Items  are  retrieved  and  passed 
to  these  modules'  superordinate. 

Identify  "Active"  Items.  This  module  obtains  the  con- 
tents of  all  the  "active-item"  record  occurrences  In  the 
database.  The  data  In  these  occurrences  uniquely  Identify 
other  record  occurrences  which  have  been  designated  "active 
(see  'Add  Active-Item  Occurrence'). 


Table  IX 


Interfaces  for  BUILD  SOFTWARE  TREE  Branch 


OUTPUT 


1,  2 CPCI  numbers,  CPC  I 
names 


Error  fla 


Error  fla 


3,  4 CPCI  number,  CPCI 
names 


5,  8,  15,  19,  22,  25,  28,  32 
Search  tables 


Record  name,  record  Identl 
fters,  error  flag 


6.  9,  16,  20,  23,  26,  29,  33 
Record  name,  record 
identifier,  field  names 


Tree  code  numbers  and 
descriptions,  error  fla 


7,  10,  17,  24,  27,  3Q,  34 

File  name,  output  line, 
line  size 


Error  fla 


11  Operating  mode  tree  code 


Error  fla 


12  CPCI  number 


Sorted  "function"  tree  codes 
error  flag 


13  Function  tree  code 


Error  fla 


Error  fla 


14  Module  tree  code 


21  Unsorted  function  tree 
codes 


Sorted  function  tree  codes, 
error  flag 


Error  fla 


31  Sub-classification 
tree  code 


. >•  - . 


Build  Software  Tree.  This  module  supervises  the  con- 
struction of  a family  tree  for  the  modules  of  each  named 

CPCI.  The  tree  is  a hierarchical  data  structue  which  de- 
scribes the  functional  organization  of  the  CPCI's  modules. 
Each  module  is  assigned  a unique  seyen-character  tree  code 
by  the  user.  This  code  is  used  to  identify  the  module  and 
the  functions  that  it  supports  within  the  CPCI.  'Build 
Software  Tree'  calls  subordinate  modules  to  construct  a 
title  page,  a hierarchical  breakdown  of  the  functions  of 
the  CPCI's  components,  and  a list  of  the  modules  (grouped 
by  function)  which  comprise  the  CPCI. 

Build  Software  Tree  Title  Page.  This  module  is  in- 
voked once  during  the  construction  of  the.  Software  Tree.  It 
locates  and  retrieves  document  identification  data  for  the 
Software  Tree  such  as  issuing  agency,  document  number,  and 
contract  number.  It  then  edits  this  data  and  writes  out- 
put lines  to  the  report  file. 

Build  Function  Section.  This  module  outputs  a 
hierarchical  description  of  the  functional  organization  of 
a CPCI's  modules.  Each  CPCI's  family  tree  consists  of  four 
levels  of  functions  Coperating  mode,  classification,  sub- 
classification,  and  function)  that  a module  can  support. 

This  module  obtains  and  outputs  a description  of  each  of 
the  operating  modes  defined  for  the  named  CPCI.  Addition- 
ally, for  each  operating  mode.  It  Invokes  subordinate 
modules  to  output  descriptions  of  component  functions  per- 
formed in  support  of  that  operating  mode. 


report  file  just  ahead  of  the  descriptions  of  the  modules 
that  perform  the  specified  function. 

Build  Module  Descriptions.  This  module  obtains  and 
writes  to  the  report  file  a description  of  each  of  the 
modules  that,  together,  perform  a single  function. 


Table  X 

Interfaces  for  DO  DESCRIBE  REQUEST  Branch 


INPUT 

1 Command  table 

2 Command  table 

3,  4,  5 

6,  7,  8 Command  table 

9,  11  File  name,  output 
line,  line  size 


10, 

22, 

23, 

24 

Item  n 

action 

code 

12, 

13, 

14 

— 

• - 

15, 

16, 

17, 

18 

Record 

19, 

20, 

21 

Fi  el 

Id  name 

OUTPUT 

Error  flag 

Transaction  sub-type, 
error  flag 

DESCRIBE  response,  error  flag 
DESCRIBE  response,  error  flag 
Error  flag 

Data  item  description, 
error  flag 

Record  names,  error  flag 
Record  description,  error  fla 
Field  description,  error  flag 


Do  DESCRIBE  Request.  This  module  Is  a transaction 
center  which  handles  requests  for  Information  about  the 
logical  structure  of  the  database.  It  determines  which 
of  the  six  possible  types  of  DESCRIBE  request  was  submitted, 
dispatches  to  the  appropriate  transaction  level  module  to 
construct  a response  to  the  request,  and  writes  the  con- 
structed response  to  the  message  file.  In  addition,  It 
writes  a message  to  the  message  file  to  Indicate  whether  or 
not  the  request  was  successfully  accomplished. 

Identify  Transaction  Sub-Type.  This  module  examines 
the  command  table's  entries  to  determine  the  type  of 
DESCRIBE  request  that  was  submitted  by  the  user.  This  may 
require  references  to  the  database  dictionary  to  determine 
If  variable  names  are  of  records  or  of  fields.  In  addition, 
the  command  table  entries  are  checked  for  consistency. 

Describe  Database  Limited.  This  module  obtains  the 
names  of  all  of  the  record  types  defined  for  the  opened 
database  realm.  These  names  are  edited  Into  a response  for- 
mat which  is  written  to  the  message  file. 

Describe  Database.  This  module  obtains  the  names  of 
all  the  record- types  defined  for  the  opened  database  realm 
and  then  obtains  edited  descriptions  of  these  records  for 
dellyery  to  the  user. 

Describe  Database  Completely.  This  module  obtains  the 
names  of  all  the  record  types  defined  for  the  opened  data- 
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base  realm,  obtains  an  edited  description  of  each  of  the 
records,  and  then  obtains  an  edited  description  of  each  of 
the  fields  that  comprise  each  record. 


Describe  Records.  This  module  obtains  an  edited 


description  of  each  record  explicitly  named  in  the  command 
table.  An  error  Indicator  Is  set  If  any  of  the  named 
records  cannot  be  found  in  the  database  dictionary. 

Describe  Records  Completely.  This  module  obtains 
edited  descriptions  of  each  record  explicitly  named  in  the 
command  table  and  of  each  field  within  each  record.  An 
error  Indicator  Is  set  If  any  of  the  named  records  cannot 
be  found  in  the  database  dictionary. 

Describe  Fields.  This  module  obtains  an  edited 
description  of  each  field  expllctly  named  In  the  command 
table.  An  error  Indicator  Is  set  If  any  of  the  named  re- 
cords cannot  be  found  In  the  database  dictionary. 

Get  Record  Names.  This  module  queries  the  database 
dictionary  for  the  names  of  all  the  types  of  records  defined 
In  the  database.  It  notifies  its  superordinate  when  an 
error  is  detected. 

Build  Record  Description.  This  module  obtains  and 
edits  a description  of  a specified  data  base  record.  A 
record's  description  will  Identify  Its:  name,  component 
filed  names,  storage  space  requirements,  key  fields,  and 
number  of  occurrences  In  the  realm.  The  module  notifies 
its  superordinate  when  any  processing  error  occurs. 
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Build  Field  Description.  This  module  obtains  and 
edits  a description  of  a specified  database  field.  A 
field's  description  identifies  the  field's  name,  length  In 
bytes,  data  type,  and  relative  position  within  the  logical 
record  In  which  It's  defined.  The  module  notifies  Its 
superordinate  when  any  processing  error  occurs. 


Figure  4-10  DO  CREATE  REQUEST  Branch 


Interfaces  for  DO  CREATE  REQUEST  Branch 


INPUT 


OUTPUT 


Error  fla 


Error  f 1 a 


3,  4 "Active"  Item  identl 
f ler 


Error  fla 


Error  fla 


Data  item  description 
error  flag 


7,  8 Record  name,  field 

names,  buffer  address 


DBMS  status  code 


9 , 10  DBMS  status  code 


Error  fla 


FIGURE  4-11  DO  MODIFY  REQUEST  Branch 


Table  XII 

Interfaces  for  DO  MODIFY  REQUEST  Branch 


i 


INPUT 


1 Search  tables,  update 

table 

2 Search  tables 


3 Update  table,  record 

name,  approved  re- 
cord Identifiers 

4 File  name,  output  line 

line  size 


OUTPUT 

Error  flag 

Approved  record  identifiers, 
record  name,  error  flag 

Error  flag 

Error  flag 


5  Item  name,  action  code 


6 Record  name,  record 

Identifier,  field 
names,  buffer  address 

7 DBMS  status  return  code 


Data  item  description, 
error  flag 

DBMS  status  return  code 


Error  flag 


8 "Active"  item  identifier  Error  flag 


I 
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Dp  MODIFY  Request.  This  module  handles  a user  request 
to  alter  the  contents  of  one  or  more  database  record 
occurrences.  It  invokes  subordinate  modules  to  identify 
the  occurrences  that  satisfy  the  search  criteria  and  to 
perform  the  database  update.  However,  prior  to  making 
any  changes  in  the  Interactive  mode,  the  module  warns  the 
user  with  a message  which  states  how  many  qualified  record 
occurrences  were  located  and  requests  his  approval  to  con- 
tinue processing  the  request.  Changing  certain  monitored 
fields  In  the  database  (such  as  ECP  priority  or  status) 
requires  that  an  active-item  record  occurrence  be  added  to 
the  database  to  register  the  event.  After  processing  the 
user's  request,  the  module  reports  the  outcome  status  of 
the  request  to  the  user  and  sets  an  error  Indicator  for  Its 
superordinate. 

Update  Record  Occurrences.  This  module  invokes  the 
DBMS  'update'  interface  routine  to  store  buffered  data  in 
the  database.  In  order  to  prepare  the  buffer  region  to 
hold  the  new  status  accounting  data,  the  module  obtains 
descriptions  from  the  database  dictionary  of  those  fields 
to  be  changed.  If  the  DBMS  status  return  code  indicates 
that  the  request  was  successfully  accomplished  and  if  the 
change  affected  a monitored  field,  an  acltye-item  record 
occurrence  is  added  to  the  database.  Any  errors  encountered 
during  request  processing  are  reported  to  the  module's 
superordinate. 


. 
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Figure  4-12  DO  DELETE  REQUEST  Branch 


I 


r 


Table  XIII 

Interface  for  DO  DELETE  REQUEST  Branch 


INPUT 

OUTPUT 

1 

Search  tables 

Error  flag 

2 

Search  tables 

Approved  record  identifiers 
record  name,  error  flag 

3, 

4 Record  name,  record 
identl fiers 

Error  flag 

5 

File  name,  output  line, 
line  size 

Error  flag 

6 

Record  name,  record 
identifier 

DBMS  status  code 

7 

DBMS  status  code 

Error  flag 
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Do  DELETE  Request.  This  module  obtains  the  identifiers 
of  record  occurrences  to  be  deleted  and  invokes  'Remove 
Record  Occurrences'  to  delete  them  (and  all  pointers  to 
them)  from  the  database.  Prior  to  making  the  deletions  In 
the  interactive  mode,  the  module  warns  the  user  with  a 
message  which  indicates  how  many  record  occurrences  were 
found  that  satisfy  the  search  criteria.  The  message  also 
requests  the  user's  approval  to  perform  the  deletions. 
Afterwards,  the  module  writes  a message  to  the  message  file 
to  Inform  the  user  about  the  outcome  status  of  his  request. 

Remove  Record  Occurrences.  When  activated,  this 
module  accepts  as  input  the  identifiers  of  those  record 
occurrences  to  be  deleted.  For  each  occurrence,  it  then 
invokes  a DBMS  Interface  routine  to  satisfy  the  user's 
request.  In  addition,  this  module  checks  the  DBMS  status 
return  code  upon  completion  of  the  request  and  sets  an 
error  Indicator  for  its  superordinate. 

Delete . This  is  a system-supplied  DBMS  interface 
module  which  calls  on  the  DBMS  to  remove  an  occurrence  of  a 
record  from  the  database. 


Figure  4-13  DO  OPEN  REQUEST  and  DO  CLOSE  REQUEST  Branches 


Table  XIV 

Interfaces  for  DO  OPEN  REQUEST  and  DO  CLOSE  REQUEST  Branches 


INPUT 

1 Command  table,  update 

tabl  e 

2 User  Identifier,  access 

mode,  realm  name 

3 DBMS  status  code 

4 File  name,  output  line 

line  size 

5 Command  table 

6 Realm  name 

7 DBMS  status  code 

8 File  name,  output 

line,  line  size 


OUTPUT 

Error  flag,  opened  realm  name 


DBMS  status  code 


Error  flat 
Error  fla< 


Error  flag 
DBMS  status  code 
Er-or  flag 
Error  flag 
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Do  OPEN  Request.  This  module  handles  a user  request 
to  prepare  a database  realm  for  processing.  It  extracts 
the  user  Identifier  and  realm  access  mode  from  the  update 
table  and  Invokes  the  system-supplied  DBMS  Interface  routine 
'Open'.  If  the  request  Is  successfully  accomplished,  the 
module  transmits  the  name  of  the  opened  realm  to  the  SOFTSAS 


executive.  The  module  will  set  an  error  indicator  for  Its 
superordinate  and  will  notify  the  user  about  the  outcome 
of  his  request. 

Open.  This  is  a system-supplied  DBMS  Interface  rou- 


tine which  calls  on  the  DBMS  to  validate  a user's  request 
for  access  to  a realm  and  to  prepare  that  realm  for  pro- 


cessing. 


Do  CLOSE  Request.  This  module  handles  a user  request 
to  discontinue  processing  of  a database  realm.  It  invokes 
a DBMS  interface  routine  to  de-allccate  the  realm,  checks 
the  DBMS  status  return  code,  notifies  the  user  about  the 
outcome  of  the  request,  and  sets  an  error  indicator  for 
its  superordinate. 

Close.  This  Is  a system-supplied  DBMS  Interface  module 
which  calls  'on  the  DBMS  to  terminate  processing  of  a realm 
and  to  de-allocate  It  from  the  program. 
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Put  Outputs.  This  module  supervises  the  delivery  of 
any  accumulated  messages  and  reports  to  an  on-line  printer 
just  prior  to  job  termination.  Output  line  Images  are 
collected  in  two  files  by  SOFTSAS  request  handlers.  One 
file  is  used  to  hold  the  reports;  the  other  is  used  to  hold 
messages,  except  when  SOFTSAS  is  executing  in  the  inter- 
active mode.  In  this  case,  messages  are  written  immediately 
to  the  user  at  his  terminal,  and  only  reports  are  put  to 
the  printer. 

Put  Messages,  Put  Reports.  These  modules  read  output 
line  images  from  the  message  and  report  files,  respectively, 
and  dispatch  them  to  the  'Write  To  Printer'  module.  The 
modules  set  error  indicators  for  their  superordinate. 

Write  To  Printer.  This  module  calls  the  system- 
supplied  I/O  routine  'Print'  to  write  a logical  record  to 
an  output  buffer  of  an  on-line  printer.  The  module  then 
checks  the  I/O  status  return  code  and  sets  an  error  indica 
tor  for  the  modules  that  invoke  it. 

Print.  This  is  a system-supplied  I/O  routine  that 
accepts  an  output  line  in  print-image  format  and  writes  it 
to  the  system' output  buffer. 
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FIGURE  4-15  READ  FROM  FILE  and  WRITE  TO  FILE  Branches 


I O 


Read  From  File.  This  module  calls  a system-supplied 
I/O  routine  to  read  a logical  record  from  a file  whose 
logical  name  Is  provided  as  an  input  parameter.  The  module 
then  checks  the  I/O  status  return  code  and  sets  an  error 
Indicator  for  its  superordinates. 

Write  To  File.  This  module  calls  a system-supplied 
I/O  routine  to  write  a logical  record  to  a file  whose  logi- 
cal name  is  provided  as  an  Input  parameter.  All  SOFTSAS 
files  will  he  located  on  mass  storage  devices  with  one 
exception.  When  SOFTSAS  Is  executing  in  the  interactive 
mode,  the  message  file  will  be  tied  to  the  user's  terminal. 
After  the  I/O  request  Is  satisfied,  the  module  will  check 
the  I/O  status  return  code  and  will  set  an  error  indicator 
for  Its  superordinates. 

Read.  This  Is  a system-supplied  I/O  routine  that 
reads  a logical  record  from  a specified  input  device  and 
stores  It  in  a program  work  area.  The  module  reports  the 
number  of  bytes  of  storage  occupied  by  the  record. 

Write.  This  is  a system-supplied  I/O  interface 
module  which  writes  logical  records  of  a specified  size  to 
a specif led -output  device. 
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FIGURE  4-16  GET  APPROVED  IDENTIFIERS  and  SEARCH  FOR 
QUALIFIED  RECORD  IDENTIFIERS  Branches 


Table  XVII 


Interfaces  for  GET  APPROVED  IDENTIFIERS  and  SEARCH  FOR 
QUALIFIED  RECORD  IDENTIFIERS  Branches 


INPUT 

1 Search  tables 


3,  6 Search  tables 


4 File  name,  output  line, 

1 ine  size 

5 File  name 


7 Record  name,  key  field 

name,  key  value, 
relational  operator, 
buffer  addr,  buffer 
size 

8 DBMS  status  return  code 

9,  10  Identifiers  list  A, 
Identifiers  list  B 


OUTPUT 

Approved  record  identifiers, 
record  name,  error  flag 

Operating  mode 

Record  name,  record 
Identifiers,  error  flag 

Error  flag 


Input  line,  line  size, 
error  flag 

Record  identifiers,  DBMS 
status  return  code 


Error  fla< 


Resultant  identifiers  list 
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Get  Approved  Identifiers.  This  module  invokes  a sub- 
ordinate to  identify  the  occurrences  of  database  records 
that  satisfy  search  criteria  contained  in  the  search  tables. 

When  SOFTSAS  is  operating  in  the  interactive  mode,  this 
module  will  write  a message  to  the  user  stating  how  many 
qualified  record  occurrences  were  located  and  requesting 
that  the  user  enter  "Yes"  or  "No"  to  continue  processing 
of  the  request.  The  module  will  then  obtain  the  user's 
response  from  input.  If  the  response  Is  negative,  the 
module  will  notify  its  superordinate  that  no  approved  re- 
cord occurrences  were  located. 

Search  for  Qualified  Record  Identifiers.  This  module 
invokes  <*  system-supplied  DBMS  interface  routine  to  obtain 
the  identifiers  of  record  occurrences  that  satisfy  specific 
search  criteria.  The  search  criteria  consist  of:  a record's 
name;  one  or  more  relational  expressions,  each  of  which  de- 
scribes a range  of  values  within  which  a qualified  occur- 
rence's  key  must  lie;  and,  a logical  relationship  between 
each  of  the  relational  expressions.  The  relational  expres- 
sions are  contained  in  the  criteria  table.  The  order  in 
which  the  criteria  table  entries  are  processed  is  dictated 
by  entries  in  the  logic  table.  Logic  table  entries  com- 
prise a postfi*  representation  of  the  user's  WHERE  clause, 
describing  the  order  in  which  logical  operations  (inter- 
section, union)  are  to  be  performed  on  the  lists  of  Identi- 
fiers. The  module  checks  the  database  status  return  code 

152 

— j.—  . ■ ■ ■ .1  "'g  f — - • 

-\V  ■ • V'/H'  - 


Figure  4-17  RETRIEVE  DATA  and  REFERENCE  DICTIONARY  Branches 


Table  XVIII 


I 


i 


Interfaces  for  RETRIEVE  DATA  and 
REFERENCE  DICTIONARY  Branches 


INPUT  OUTPUT 

1  Record  name,  record  Retrieved  data,  error  flag 

Identifiers,  field 
names 


r 


2 Record  name,  record 

identifier,  field 
names,  buffer  addr, 
buffer  size 

3 DBMS  status  code 

4 Field  names 

5,  6 Item  names,  action 
code 

7 Action  code.  Item  name, 

buffer  address 

8 DBMS  status  code 


Retrieved  data,  DBMS  status 
code 

Error  flag 

Relative  buffer  addresses 

Data  item  description, 
error  flag 

Data  item  description, 

DBMS  status  code 

Error  flag 
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Retrieve  Data.  This  module  invokes  a system-supplied 
DBMS  interface  routine  to  copy  specific  items  of  data  from 
a database  record  occurrence  into  a buffer.  It  also  calls 
a subordinate  to  identify  the  data  type  and  relative  buffer 
location  for  each  item  that  was  obtained.  If  no  fields  are 
named,  data  from  each  of  the  fields  in  the  record  are  ob- 
tained. The  module  checks  the  DBMS  status  return  code, 
setting  an  error  Indicator  for  its  superordinate. 

Reference  Dictionary.  This  module  invokes  a system- 
supplied  DBMS  interface  routine  to  retrieve  a description 
of  a particular  part  of  the  logical  structure  of  the  data- 
base. It  then  checks  the  DBMS  status  return  code  and  sets 
an  error  indicator  for  its  superordinates. 

Get-Data.  This  is  a DBMS  interface  module  which  calls 
on  the  DBMS  to  retrieve  data  from  specific  fields  in  a 
single  record  occurrence. 

Identify  Buffer  Format.  This  module  determines  the 
format  in  which  the  retrieved  data  items  were  stored  by 
the  DBMS  In  a buffer.  As  required,  it  obtains  record  and 
field  descriptions  from  the  database  dictionary. 

Get-Djct.  This  is  a DBMS  interface  module  which  calls 
on  the  DBMS  to  obtain  database  descriptive  information  from 
the  database  dictionary.  A specified  "action  code"  in- 
structs the  module  to  retrieve  either  record  names,  record 
descriptions,  or  field  descriptions. 
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Figure  4-18  CHECK  I/O  STATUS  and  CHECK  DATABASE  STATUS  Branches 


Check  I/O  Status,  Check  Database  Status.  These  modules 
inspect  database  and  I/O  status  return  codes,  respectively. 
When  either  of  these  modules  detects  that  an  error  has 
occurred,  it  generates  an  error  message,  writes  it  to  the 
message  file,  and  sets  an  error  indicator  for  its  super- 
ordfnates . 


Observations 
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Abstraction . The  structure  charts  presented  in  this 
chapter  constitute  a preliminary  design  for  SOFTSAS  which 
will  require  refining  before  it  can  be  used.  It  is  an 
abstract  solution  to  the  general  status  accounting  problem. 
The  descriptions  of  the  modules  and  the  data  communicated 
between  them  were  specified  such  that  flexibility  in  the 
choice  of  a more  specific  implementation  was  provided. 

For  example,  a user's  Input  request  is  converted  to  an 
internal  form  and  is  stored  in  various  "Internal  tables". 

But  a format  was  not  provided  for  the  tables,  and  the 
manner  In  which  they  are  to  be  passed  as  arguments  (i.e. 
by  name  or  by  value)  was  not  identified. 

Modi f iabil i ty.  The  Structured  Design  approach  to 
hierarchically  functional  decomposition  enhances  the 
modifiability  of  the  system.  As  reflected  by  the  structure 
charts,  a user's  input  request  is  read  and  completely 
analyzed  by  the  'Get  Analyzed  Request’  module  before  being 
converted  to  an  Internal  form.  Since  knowledge  of  the 
formats  of  submitted  requests  is  localized  to  one  sub-tree 
of  the  program's  hierarchy,  these  formats  can  be  changed 
without  impacting  other  parts  of  the  program.  In  addition, 
the  design  readily  allows  for  more  serious  changes  as  well. 
Implementation  of  a DBMS  which  communicates  entire  records 
of  data  Instead  of  individual  fields  would  require  changes 
to  the  modules  that  prepare  and  Interpret  the  database 
buffer  as  well  as  those  that  Interface  with  the  DBMS.  Also, 
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such  a change  may  require  that  module  'Update  Record 
Occurrences'  first  retrieve  data  that  is  to  remain  unaltered 
in  order  to  completely  specify  the  record's  new  contents. 
Although  these  changes  may  be  substantial,  the  affects  are 
still  localized  to  a set  of  well-defined  modules  whose 
identity  can  readily  be  dtermined  from  the  charts. 

Error  Handling.  Although  decomposing  a program  into 
highly  independent  modules  makes  it  less  complex  and  easier 
to  develop,  test,  and  modify,  there  is  no  way  to  ensure 
that  a program  will  always  execute  correctly  (Ref  22). 
Therefore  one  of  the  primary  goals  of  software  design  is  to 
build  a program  that  is  reliable.  For  software,  reliability 
is  defined  as  the  probability  that  a software  error  does 
not  cause  deviation  from  required  output  by  more  than 
specified  tolerances  in  a specified  environment  over  a 
specified  time  interval  (Ref  31,  38:5,2).  For  a program  to 
be  reliable,  its  errors  must  be  reported  when  they  occur, 
and  their  adverse  effects  must  be  minimized.  This  requires 
that : 

a.  Processing  errors  be  detected  at  the  earliest 
possible  time; 

b.  Errors  be  prevented  from  propagating  and  damaging 
other  parts  of  the  system;  and, 

c.  An  attempt  be  made  to  recover  any  losses  or  damages 
(Ref  11:337-338,  4Q:429l. 

The  third  requirement  implies  that  a program  abort  should 
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not  occur;  this  would  only  preclude  the  possibility  of 
instantaneous  recovery  attempts  and  loss  minimization. 

"In  most  cases,  the  module  detecting  an  error  should 
not  be  the  module  which  corrects  it"  CRef  29:3591.  Often, 
errors  are  dtected  by  modules  at  low  levels  of  a program's 
structural  hierarchy.  These  modules  are  usually  designed 
to  perform  a function  that  can  be  used  in  many  applications. 
It  is  not  desirable  that  these  modules  handle  "exception 
processing"  because  it  tends  to  limit  their  re-usability. 

In  addition,  what  appears  to  be  an  error  condition  at  a 
low  level  may  constitute  an  acceptable  condition  at  a higher 
level.  (An  example  of  this  might  be  a "no  data  qualify" 
condition  for  a data  retrlevel  request.)  But  neither  is  it 
desirable  to  complicate  high-level  modules  by  having  them 
react  to  errors  that  can  be  handled  at  lower  levels.  A 
rule  of  thumb  is  that  errors  should  be  handled  by  the 
lowest  level  module  having  sufficient  knowledge  to  direct  a 
recovery.  When  recovery  is  not  possible,  the  problem 
should  be  passed  to  higher-level  modules  to  be  resolved. 

The  SOFTSAS  modules  which  will  most  often  detect  pro- 
cessing errors  are  those  which  interface  with  the  I/O 
facility  or  with  the  DBMS  and  those  which  see  parts  of  sub- 
mitted user  requests.  When  a processing  error  is  detected, 
SOFTSAS  will  notify  the  user,  reporting: 

a.  The  type  of  error  that  occurred; 

b.  A description  of  the  data  that  was  in  error; 
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c.  An  tndtcatlon  of  the  outcome  of  any  recovery 
actions  that  the  program  attempted;  and, 

d.  A suggestion  for  avoiding  a reoccurrence  of  the 
error. 

[When  executing  in  batch  mode,  a non-recoverabl e error 

will  cause  the  SOFTSAS  executive  module  to  terminate 


execution  of  the  program.  However,  when  executing  in  the 
interactive  mode,  only  execution  of  the  request  will  be 
terminated.  In  either  case,  the  "error-detecting"  modules 
need  some  medium  for  communicating  the  presence  of  the 
error  to  the  program  executive.  Many  of  the  module  inter- 
faces defined  in  the  preceeding  section  contain  an  output 
parameter,  "error  flag",  to  inform  a module's  superordinate 
when  it  perceives  that  a detected  error  is  non-recoverabl e . 
If  the  superordinate  cannot  effect  a recovery  of  its  own, 
it  will  pass  the  error  notification  along  to  its  superordi- 
nate. Since  there  is  no  specification  for  a host  machine 
or  a DBMS  as  yet,  the  specific  error  types  and  related  re- 
covery procedures  have  not  been  defined  in  this  thesis. 

Summary 

This  chapter  presented  the  design  specification  for 
SOFTSAS  which  was  developed  using  the  Structured  Design 
strategies  of  transform-analysis  and  transaction-analysis. 
The  design  was  derived  by  conceptualizing  the  formal  func- 
tional specifications  as  data  flows  and  then  following  the 
design  guidelines  set  forth  by  Constantine.  A modification/ 
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V Database  Design 


Database  processing  consists  of  three  components:  the 
user's  applications  programs,  the  database  management  sys- 
tem CDBMS) , and  the  database  itself.  Chapter  II  discussed 
the  functions  that  the  DBMS  must  perform  in  order  to  support  , 
SOFTSAS,  and  Chapter  IV  suggested  a SOFTSAS/DBMS  interface. 
Although  the  design  of  a DBMS  is  beyond  the  scope  of  this 
thesis,  this  chapter  presents  a model  which  describes  a 
logical  structure  for  the  database  on  which  the  SOFTSAS  DBMS 
will  operate. 
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Database  Modelling 

Succinctly  stated,  a database  is  a collection  of  inter- 
related data  items  stored  to  serve  multiple  applications. 

The  description  of  a database  takes  two  forms.  A physical 
description,  of  interest  to  systems  programmers  and 
designers,  specifies  the  manner  in  which  the  data  items  are 
physically  stored  and  referenced  on  the  hardware.  A 
logical  description,  used  by  applications  programmers  and 
users,  specifies  a format  for  each  of  the  data  items  and 
identifies  the  relationships  among  the  data  items  as  per- 
ceived by  the  user. 

Application  programs  use  logical  data  descriptions  to 
communicate  with  the  DBMS.  The  DBMS  converts  these  into 
physical  descriptions  which  it  uses  when  invoking  the  basic 
input/output  routines  of  the  host  operating  system.  This 
two-tiered  system  for  referencing  the  data  protects  appli- 
cation programs  from  physical  data  storage  considerations, 
thus  enhancing  their  modifiability. 

The  logical  structure  of  a database  is  modelled  at  two 
levels  of  abstraction  called  the  schema  and  the  sub-schema, 
respectively  (.Ref  10)*  A schema  is  an  overall  description 
of  the  true  logical  structure  of  all  the  data  contained  in 
the  database;  it  is  defined  and  controlled  by  the  Database 
Administrator.  But  since  a database  serves  multiple  appli- 
cations, individual  applications  seldom  utilize  all  the 
data  it  contains.  In  addition,  two  applications  may  each 
view  differently  the  data  that  they  share.  Therefore, 
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sub-schemas  are  used  to  describe  subsets  of  the  database 
for  individual  applications.  Despite  their  differences, 
both  schemas  and  sub-schemas  are  "maps"  which  describe  the 
structure  of  data  items  and  the  associations  among  them. 
These  maps  can  be  drawn  in  man/  ways. 

Canonical  Models 

Martin  (Ref  2Q : 248- 29Q ) has  proposed  a methodology  for 
obtaining  a "canonical"  schema  from  a set  of  user  views  of 
the  data.  He  defines  a canonical  schema  as,  "A  model  of 
data  which  represents  the  inherent  structure  of  that  data 
and  hence  is  independent  of  individual  applications  of  the 
data  and  also  of  the  software  or  hardware  mechanisms  which 
are  employed  in  representing  and  using  the  data"  (Ref  20: 
248).  His  approach  is  as  follows. 

Each  end-user's  view  of  the  data  is  analyzed  to  obtain 
a bubble  chart  consisting  of  the  data  item  types  (bubbles) 
and  the  associations  among  them  (directed  links)  that  are  of 
interest  to  the  user.  Between  any  two  data  items,  A and  B, 
there  are  two  possible  types  of  associations.  First,  there 
can  be  a one-to-one  mapping  (1-association)  from  data  item 
A to  data  item  B such  that  each  value  of  A always  uniquely 
identifies  one  value  of  B.  This  type  of  association  would 
be  reflected  on  the  bubble  chart  by  a single-headed  arrow 
connecting  A to  B.  Second,  there  can  be  a one-to-many 
mapping  (M-assoclation)  such  that  each  value  of  A Identifies 
zero,  one,  or  more  values  of  B.  This  type  of  association 
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would  be  reflected  by  a double-headed  arrow  on  the  bubble 
chart  connecting  A to  B.  In  some  cases,  arrows  will  be 
used  that  point  both  from  A to  B and  from  B to  A. 

Once  the  bubble  charts  have  been  developed  for  each 
user,  they  are  combined  according  to  a specific  procedure 
(Ref  20:274-276)..  The  procedure  essentially  entails 
merging  user  views,  one  at  a time,  such  that  redundancies 
In  data  and  relationships  are  eliminated  while  user-defined 
logical  structures  are  preserved.  The  result  Is  a canoni- 
cal model  for  the  database  which  can  be  implemented  using 
one  of  several  database  management  systems,  including 
CODASYL  DBTG-based  software,  DL/l-based  software,  and  rela- 
tional database  software. 

A canonical  model  Is  Interpreted  as  follows.  The  pri- 
mary keys  are  those  bubbles  which  have  one  or  more  single- 
headed arrows  leaving  them.  (A  primary  key  that  consists 
of  more  than  one  data  Item  is  called  a concatenated  key, 
and  its  items  are  treated  as  a unit.)  The  secondary  keys 
are  those  bubbles  which  have  one  or  more  double-headed 
arrows  leaving  them.  A record  consists  of  a primary  key 
and  data  items  (called  attributes)  that  satisfy  the  fol- 


lowing two  criteria:  a.  The  attribute  must  be  fully  func- 
tionally dependent  on  the  entire  primary  key;  b.  The  attri- 
bute cannot  be  functionally  dependent  on  any  other  attribute 
in  the  record,  unless  that  other  attribute  could  Itself  be 


used  as  the  record's  primary  key 


SOFTSAS  Canonical  Schema 

The  canonical  schema  presented  fn  this  thesis  models 
software  configuration  status  accounting  (_CSA)  data  of  con- 
cern to  AFSC  program  managers.  The  schema  was  derived  by 
analyzing  "user  views"  of  the  data.  However,  a user  was 
not  considered  to  be  a software  configuration  manager; 
rather,  a user  was  considered  to  be  a section  of  a CSA  re- 
port to  be  produced  for  that  manager.  For  example,  to 
satisfy  the  CSA  requirements  of  the  SIMSPO,  a total  of  8 
sections  for  3 reports  need  to  be  constructed  on  a periodic 
basis  (see  Chapter  III);  thus,  there  are  at  least  8 separate 
user  views  of  the  data  for  the  SIMSPO.  Once  a preliminary 
schema  was  derived,  additional  data  that  would  be  useful 
to  SIMSPO  software  configuration  managers,  both  now  and 
possibly  at  some  later  time,  were  also  Included.  The  schema 
that  evolved  models  the  software  CSA  data  for  only  one  AFSC 
program  office.  However,  since  a canonical  schema  portrays 
the  inherent  relationships  among  data,  and  since  much  of 
the  software  CSA  data  to  be  reported  to  AFSC  program  offices 
is  the  same  (the  formats  of  the  reports  are  what  differ 
most).  It  is  felt  that  the  CSA  reporting  requirements  of 
other  SOFTSAS  users  within  AFSC  could  be  satisfied  without 
radical  changes  to  the  model. 

Figure  5-1  and  Figures  C-l  through  C-27  In  Appendix  C 
portray  the  canonical  schema  for  the  SOFTSAS  database. 

Figure  5-1  identifies  the  logical  database  records  (bubbles) 
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and  the  relationships  among  them  (.arrows  1.  The  figures  in 
the  appendix  descrihe  the  contents  of  these  records. 

Each  of  Figures  C-l  through  C - 27  describes  one  com- 
plete database  record.  A record  Is  depicted  as  a set  of 
conjoined  boxes,  each  of  which  identifies  a data  item  be- 
longing to  the  record.  The  contents  of  the  first  box  in 
each  figure  are  underlined  for  emphasis  because  they  identify 
the  record's  primary  key.  Data  items  that  form  a concate- 
nated key  are  co-located  in  the  first  box  and  are  separated 
by  a plus  C+)  sign.  The  other  boxes  identify  the  record's 
attributes.  Although  the  single-headed  arrows  directed 
from  the  record's  primary  key  to  each  of  its  attributes  were 
deleted,  a double-headed  arrow  was  retained  to  identify 
where  an  attribute  is  to  be  used  as  a secondary  key. 

Table  C-I  defines  each  of  the  data  items  named  In  the 
schema.  Format  descriptions  for  most  of  the  items  can  be 
found  in  MIL-STD-482A. 
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Summary 


This  chapter  presented  a canonical  schema  to  describe 
the  structure  of  the  status  accounting  database.  The 
schema  was  derived  from  the  user's  views  of  the  data. 
Unfortunately,  most  database  management  systems  today  cannot 
use  canonical  schemas.  However,  it  is  a relatively  straight- 
forward process  to  convert  this  schema  Into  any  of  several 
logical  structures  that  can  be  implemented  with  present-day 
database  management  systems.  Despite  the  overhead  for  con- 
version, the  canonical  schema  is  useful  because  it  provides 
a "minimal  structure"  for  the  database  and  identifies  the 
best  way  to  group  and  interconnect  the  data:  according 
to  its  Inherent  properties. 


VI  Conclusion 


Observations 

Status  accounting  is  an  essential  element  of  configura- 
tion management  which  can  contribute  significantly  to  the 
success  of  an  acquisition  program.  Historically,  accounting 
for  CPCIs  has  been  neglected  In  favor  of  the  more  visible, 
and  usually  more  expensive,  CIs.  But  with  the  rise  in  soft- 
ware costs  and  complexity,  configuration  management  of  CPCIs 
i s essential . 

The  CSA  report  requirements  presented  in  Chapter  II 
were  tailored  to  the  needs  of  the  Simulator  SPO  and  may  not 
be  appropriate  for  other  procurement  agencies.  This  is  be- 
cause AFSC  configuration  management  policies  and  procedures 
give  program  offices  flexibility  in  accounting  for  the 
status  of  their  configuration  items.  Since  program  offices 
are  directed  to  obtain  only  that  information  needed  to  effec 
tively  and  economically  do  that,  the  potential  exists  for 
much  variation  in  their  status  accounting  requirements. 

General  designs  for  a modifiable  computer  program  plus 
a comprehensive  database  were  presented  in  Chapters  IV  and 
V.  They  were  derived  without  any  specific  hardware,  DBMS, 
support  software,  or  programming  language  constraints. 

These  constraints  could  not  be  specified  because  each  pro- 
gram office  determines  the  agency  to  perform  the  status 
accounting  function  (.ttself  or  the  contractor)  based  on  cost- 
effectiveness  considerations.  To  have  imposed  a standard 
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set  of  constraints  would  have  been  counterproductive,  parti- 
cularly since  many  contractors  already  have  hardware  and 
support  software  available  for  use.  The  designs  can  be  more 
stringently  specified  only  after  an  external  environment  has 
been  defined  for  a particular  application  of  SOFTSAS. 

One  desirable  requirement  not  levied  on  SOFTSAS  by  the 
SPO,  yet  included  In  the  requirements  definition,  was  for 
an  interactive  processing  capability.  Interactive  proces- 
sing allows  a user  to  communicate  with  the  software  as  it  is 
executing.  This  can  be  used,  for  example,  to  verify  which 
records  in  the  database  will  be  affected  by  a specific  update 
request  just  prior  to  submitting  the  request.  In  addition, 
it  lets  users  spontaneously  correct  certain  types  of  errors 
detected  by  the  software  without  having  to  terminate  execu- 
tion of  the  program.  However,  interactive  processing  is  most 
suited  to  those  users  with  small,  inconstant  input  streams 
such  as  those  employed  when  updating  the  database.  Since 
the  Simulator  SPO  program  managers  anticipate  contracting 
for  status  accounting  services,  they  did  not  levy  the 
interactive  processing  requirement  on  SOFTSAS.  Nevertheless, 
the  capability  was  considered  desirable  enough  to  conceivably 
be  required  by  other  SOFTSAS  users. 

A conclusion  was  reached  that  the  data  management  func- 
tion could  best  be  performed  in  a database  processing  environ 
ment.  A DBMS  would  "hide"  information  from  SOFTSAS  about  the 
physical  storage  of  the  data  and  would  provide  a range  of 
options  to  protect  the  data  from  misuse  and  abuse.  This 
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simplifies  the  SOFTSAS  program  requirements,  thus  enhancing 
its  maintainability  and  reducing  SOFTSAS  life-cycle  costs, 
particularly  when  a contractor's  DBMS  Is  used.  In  addition, 
increases  in  program  efficiency  can  be  realized  because  a 
DBMS  provides  the  means  by  which: 

a.  Data  redundancy  in  the  system  can  be  reduced; 

b.  The  same  data  can  be  perceived  and  used  In  different 
ways  by  different  users; 

c.  The  data  can  be  obtained  using  different  access 
paths;  and, 

d.  Data  standardization  can  be  achieved. 

The  logical  structure  for  the  database  was  defined  In 
terms  of  a canonical  schema.  A canonical  schema  depicts 
the  "real-world"  relationships  between  the  items  of  data: 
without  DBMS  or  physical  storage  constraints.  It  is  con- 
structed from  a collection  of  user  views  together  with 
assumptions  about  future  uses  of  the  data.  Although  a canoni- 
cal schema  cannot  be  implemented  with  all  DBMS  software 
packages.  It  can  be  used  to  derive  a database  schema  for 
most  hierarchical,  CODASYL  DBTG-based,  and  relational  sys- 
tems. This  conversion  step  would  be  relatively  straightfor- 
ward to  an  analyst  who  is  familiar  with  the  data  definition 
language  of  the  target  DBMS. 

The  database  model  presented  in  this  report  was  called 
a schema.  ...  Indeed,  it  is  a schema  for  software  CSA  applica- 
tions within  AFSC.  However,  the  model  Is  really  a sub-schema 
which  should  be  merged  with  other  sub-schemas  (such  as  those 
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for  hardware  CSA,  manpower  accounting,  and  budgeting)  to 
form  a more  comprehensive  model  of  an  organization's  data. 


In  this  way,  an  organization ' s data  can  be  processed  as  an 


integrated  whole. 


Recommendations 


Once  an  external  environment  is  specified  for  SOFTSAS, 


the  design  presented  earlier  can  be  refined.  But  since  many 


designs  can  be  derived  for  a particular  system,  it  is  impor- 


tant that  alternative  designs  be  developed  and  the  best  one 


selected  for  full-scale  development. 


Several  software  design  methodologies  are  currently  in 


vogue  (Ref  21).  For  example,  the  Structured  Design  technique 


derives  a design  from  an  analysis  of  the  flow  of  data  assoc- 


iated with  the  problem;  other  techniques  rely  on  aspects 


such  as  the  flow  of  control  or  the  structure  of  the  data 


associated  with  the  problem.  These  methodologies  are  not 


firm  rules,  but  rather  are  guidelines  which  identify  trade- 


offs so  that  intelligent  choices  can  be  made.  Thus,  obtain- 


ing several  competing  designs  for  a computer  program,  even 


when  using  the  same  technique,  will  not  be  technically  dif- 


ficult; but  as  yet,  comparing  them  will. 


Research  in  the  areas  of  software  engineering  and  soft- 


ware quality  assurance  has  identified  some  attributes  of 


software  quality  and  some  measurable  program  characteristics 


that  have  been  demonstrated  to  affect  these  attributes  (Ref 


8,13,14,24:81-85,38:4,68-71).  Some  of  the  characteristics 


reflect  the  logic  complexity  and  the  documentation  of  a 


module;  these  pertain  more  to  the  implementation  of  a module 
than  to  the  design  of  the  program.  However,  other  character- 
istics reflect  the  way  in  which  processes  are  allocated  to 
the  program's  modules  and  the  way  In  which  these  processes 
are  connected;  these  pertain  directly  to  the  design  of  the 
program. 

In  order  to  select  the  best  of  several  competing  de- 
signs, the  quality  attributes  to  be  built  Into  the  software 
must  first  be  identified.  Second,  any  conflicts  between  the 
attributes  (Ref  8:594,19:46-47)  must  be  resolved,  and  the 
levels  of  quality  to  be  achieved  for  each  attribute  must  be 
explicitly  stated  in  the  software's  specifications.  Finally, 
tools  with  which  to  measure  a design's  compliance  with  its 
specifications  and  to  measure  its  cost-effectiveness  against 
that  of  other  designs  must  be  developed.  Myers  (Ref  24:137- 
149)  for  one  has  proposed  a model  to  quantify  the  indepen- 
dence of  modules  in  a program  in  order  to  evaluate  the  pro- 
gram's complexity  and,  hence,  its  maintainability.  However, 
much  work  remains  to  be  done  in  the  area  of  quantifying  soft- 
ware metrics. 

Before  much  effort  is  expended  in  preparing  more  de- 
tailed designs  for  SOFTSAS,  consideration  should  be  given 
to  whether  a software  status  accounting  system,  separate 
from  a system  for  hardware,  is  truly  required.  It  is  felt 
that,  by  modifying  the  preliminary  SOFTSAS  design  (primarily 
the  report  generator  modules!,  a single  status  accounting 
system  could  serve  both  purposes.  In  addition,  by  expanding 


* 


the  database  to  Include  a structure  for  hardware  data  Csuch 
as  spares  status  and  equipment  effecti vity) , only  a single 
database  need  be  maintained.  These  actions  would  not  only 
reduce  software  costs,  but  would  also  allow  for  combined, 
yet  distinct,  status  reporting  of  CIs  and  CPCIs  being 
acquired  for  a system. 

In  addition,  some  enhancements  to  the  basic  SOFTSAS 
requirements  should  be  considered  by  the  user.  For  example, 
a new  input  keyword  could  be  used  together  with  a clause 
Identifier  to  signal  SOFTSAS  to  re-use  a parameter  specified 
in  the  previous  request.  Also,  SOFTSAS  could  be  designed  to 
perform  some  arithmetic  or  statistical  functions  on  the  data 
upon  request.  One  use  of  these  functions,  for  example, 
might  be  to  compute  the  average  number  of  ECPs  per  quarter 
that  were  incorporated  behind  schedule  into  the  CPCIs  of 
a system  over  the  course  of  the  previous  year. 

Beyond  SOFTSAS  design,  it  is  recommended  that  a rigorous 
specification  for  SOFTSAS  coding  practices  be  developed. 

For  example,  restrictions  should  be  placed  on  the  use  of: 

a.  Poorly  commented  code; 

b.  Assembly  language  when  a high-level  language  can 
be  used; 

c.  Language  constructs  which  allow  a program  to  modify 
Itself;  and, 

d.  Aberrant  statements  or  algorithms  to  gain  marginal 
efficiencies  in  speed  or  memory. 


Moreover,  use  of  programming  techniques  such  as  structured 
programming  and  self-check  coding  should  be  encouraged.  When 
enforced,  these  practices  enhance  the  maintainability  and 
usability  of  the  program  because  the  resulting  code  is  made 
more  understandable. 

It  is  also  recommended  that  a centralized  CSA  data  bank 
be  used  when  more  than  one  contractor  is  involved  In  the 
development  of  a system.  Separate  contractors  often  work 
on  the  same  system  when  functional  requirements  are  allocated 
among  several  CIs  and  CPCIs.  In  such  cases,  consideration 
should  be  given  to  designating  one  contractor  to  engineer 
the  development  of  the  entire  system  (Ref  5:32-33).  He 
could  then  be  assigned  the  respons i bi 1 i ty  of  integrating 
all  the  status  accounting  Information  and  producing  the 
required  reports.  This  would  not  only  reduce  CSA  costs, 
but  it  would  also  make  CSA  more  responsive  to  the  informa- 
tion needs  of  the  system's  configuration  managers. 

As  the  number  of  SOFTSAS  users  Increases,  status 
accounting  data  elements  and  data  relationships  will  un- 
doubtedly be  identified  which  are  not  represented  by  the 
database  model.  If  the  new  data  elements  are  not  documented 
in  MIL-STD-482A , they  should  be  forwarded  to  the  custodian 
of  the  standard  for  approval  and  incorporation  (Ref  24:1). 

In  addition,  an  effort  should  be  made  to  maintain  the  cano- 
nical schema  presented  In  Chapter  V,  thus  enhancing  Its 
usefulness  as  a guide  for  structuring  (or  restructuring) 
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status  accounting  databases.  In  fact,  it  is  felt  that  such 
a model  could  itself  be  a worthwhile  addition  to  MIL-STD- 
482A,  and  consideration  should  be  given  to  incorporating  it 
in  the  standard.  This  would  also,  in  effect,  assign  main- 
tenance responsibility  for  the  model. 

Finally,  the  measure  of  SOFTSAS'  effectiveness  will  be 
whether  or  not  it  provides  the  information  that  a software 
configuration  manager  needs  in  a timely  and  accurate  manner. 
Therefore,  specifications  for  the  use  of  SOFTSAS  must 
necessarily  include  such  details  as: 

a.  When  should  SOFTSAS  reporting  begin; 

b.  When  should  an  item  be  added  to  the  database; 

c.  How  frequently  should  reports  be  provided,  and  to 

whom; 

d.  How  long  should  an  item  continue  to  be  reported; 

e.  Under  what  circumstances  should  an  item  be  deleted 
from  the  database;  and, 

f.  How  quickly  must  unanticipated  requests  for  reports 
be  satisfied? 

Although  these  details  deal  more  with  human  interaction  with 
the  system  than  with  computer  support  for  the  system,  varia- 
tions in  these  "design"  requirements  will  affect  what  infor- 
mation the  manager  receives  and  thereby  affect  his  ability 
to  manage  his  acquisition  program. 
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Appendix  A 

STRUCTURED  ANALYSIS  DIAGRAMS 
(excerpted  with  permission  from  Ref  3Q1 


Introduction 

This  appendix  contains  a brief  explanation  of  the  func- 
tional analysis  phase  of  structured  analysis  to  aid  the 
reader  In  understanding  the  development  of  the  design  struc- 
ture. A more  detailed  discussion  can  be  found  In  Ref  35. 

Structured  Analysis 

Structured  analysis  Is  a comprehensive  methodology  for 
performing  functional  analysis  and  design.  In  the  functional 
analysis  phase,  the  emphasis  Is  on  analyzing  and  documenting 
"what"  the  system  Is  supposed  to  do.  Two  sets  of  diagrams 
result:  one  describes  the  system  In  terms  of  activities, 
the  other  describes  the  system  in  terms  of  data.  These  dia- 
grams are  created  by  decomposing  the  system  onto  smaller  and 
smaller  pieces.  The  two  sets  of  diagrams  are  cross-checked 
and  sequenced  to  provide  a model  of  the  system  functions. 

Diagram  Syntax 

* 

Structured  analysis  diagrams  consist  of  labeled  boxes 
and  arrows  for  expressing  the  system  activity  and  data 
models.  Figure  A-l  Illustrates  the  basic  syntax  of  the 
models.  Inside  a box  Is  the  name  of  the  activity  model  or 
data  model.  For  an  activity  model  the  name  expresses  the 
action  taking  place.  For  a data  model  the  name  Is  a noun  or 
noun  phrase  expressing  the  data  Item. 
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2.  Output:  Data  created  by  the  activity. 

3.  Control:  Data  used  to  control  the  process  of 
converting  the  Input  Into  output. 

4.  Mechanism:  The  processor  which  performs  the 
activity  Cperson  computer,  program,  etc.} 

B.  Data  Diagrams: 

1.  Input:  Activity  which  creates  the  data. 

2.  Output:  Activity  which  uses  the  data. 

3.  Control:  Activity  which  controls  the  creation 
or  use  of  the  data. 


4.  Mechanism:  The  storage  device  used  to  hold  the 
data  (buffer,  computer  memory,  etc.} 


the  "mechanism"  arrow  repre- 
sents  the  tool  necessary  to 
"realize  the  box"  (Ref  3 5 : 3 ~ 4 ) 
since  it  Is  usually  evident 


mechanism"  arrow  Is  not  always 


shown 


The  "mechanism  call"  arrow 


points  downward.  This  indi- 
cates a separate  system  which 
completely  performs  the  func- 
tion of  the  box.  In  such 
cases  there  will  be  no  child 
diagram  of  the  box  and  Its 


A-2  Mechanism  Call  Arrow 


TWO-WAY  BRANCH 


A-3  OR  Branch  and  Join  Structure 


detail  would  be  found  In  a separate  model  of  the  mechanism 
This  "mechanism  call'*  Is  illustrated  In  Figure  A-2. 

The  "multiple  branch"  (EXCLUSIVE  OR)  Is  used  to  Indi- 
cate multiple,  but  not  simultaneous,  outputs.  The  "multi- 
ple join"  Indicates  multiple,  but  not  simultaneous,  inputs 
Both  conventions  are  Illustrated  in  Figure  A-3. 

An  "ICOM  Code"  Is  used  to  connect  arrows  across  the 


parent/child  boundaries.  The  name  ICOM  is  derived  from  the 
arrow  names:  1_nput,  £ontrol , output,  and  mechanism.  Each 
boundary  crossing  arrow  (ones  which  do  not  have  both  ends 
connected  to  a box)  is  labeled  with  Its  parent-context  ICOM 
code.  In  addition  to  Its  normal  label.  This  aids  the  reader 
In  locating  the  matching  parent  arrow.  The  "ICOM  Code"  Is 
written  near  the  unconnected  end  of  the  arrow  and  consists 
of  the  letter  I,  C,  0,  or  M followed  by  a number.  This 


number  gives  the  relative 
position  that  the  arrow  en 
ters  or  leaves  the  side  of 
the  parent  box.  Numbering 
Is  done  from  left  to  right 
and  top-to-bottom  as  illus 
trated  In  Figure  A-4.  For 
example,  "C2"  on  an  arrow 
in  a child  diagram  indi- 
cates the  arrow  Is  the  se- 
cond control  arrow  entering  a-4  ICOM  Numbering  Convention 
the  parent  box. 

In  the  text  associated  with  each  diagram,  the  arrows 
are  Identified  with  an  "ICOM  code"  consisting  of  a letter 
(I,  0,  C or  M),  a prefix  number,  and  a suffix  number.  The 
prefix  number  refers  to  the  box  within  the  diagram  and  the 
suffix  number  refers  to  the  top-down  or  left-right  order  of 
the  arrow  on  the  box.  For  example,  "2C3"  means  the  third 
control  going  into  box  2 on  the  diagram. 

Reading  Sequence  (Ref  35:4-2) 

The  following  sequence  is  suggested  for  reading  each 
diagram  in  a top-down  order. 

1.  Scan  only  the  boxes  of  the  diagram  to  gain  a first 
Impression  of  Its  decomposition. 

2.  Using  the  parent  diagram,  rethink  the  message  of  the 
parent,  observing  the  arrows  feeding  to  and  from  the  current 
diagram. 


3.  Referring  back  to  the  current  diagram,  see  how 

and  where  each  arrow  from  the  parent  context  attaches  to  the 
factors  In  the  current  diagram:  using  ICOM  codes. 

4.  Consider  the  internal  arrows  of  the  current  diagram 
to  see  how  It  works  in  detail.  Consider  the  boxes  from  top 
to  bottom  and  from  left  to  right.  Examine  the  arrows  by 
going  clockwise  around  each  box. 

5.  Finally,  read  the  text  of  the  current  diagram  to 
confirm  or  to  alter  the  Interrelation  gained  from  considera- 
tion of  the  diagrams  themselves. 


Appendix  B 

STRUCTURED  DESIGN  CHARTS 
(excerpted  with  permission  from  Ref  30] 


Introduction 

This  appendix  contains  a brief  explanation  of  structured 
design  in  order  that  the  reader  may  understand  the  develop- 
ment and  the  reading  of  the  structured  charts.  A more  de- 
tailed discussion  can  be  found  in  Ref  11. 

Structured  Design 

Structured  design  is  a set  of  general  program  design 
considerations  and  techniques  for  making  coding,  debugging, 
and  modification  easier,  faster,  and  less  expensive  by  re- 
ducing complexity.  It  simplifies  the  software  by  dividing 
It  Into  modules  In  such  a way  that  the  modules  can  be  imple- 
mented and  modified  with  minimal  effect  on  other  parts  of 
the  system. 

Structured  design  starts  by  stating  a problem  as  a data 
flow  graph,  or  bubble  chart.  A first  cut  obtained  by  factor- 
ing the  bubble  chart  into  a tree  structure.  The  resulting 
design  Is  then  evaluated. 

The  criteria  for  evaluating  the  design  are  coupling  and 
cohesion.  Coupling  is  a measure  of  the  relationship  between 
modules,  and  cohesion  is  a measure  of  the  rel ations-,1  ps  be- 
tween modules,  and  cohesion  is  a measure  of  the  relation- 
ships among  elements  In  the  same  module.  The  objective  Is 
to  minimize  coupling  and  to  maximize  cohesion.  Other 
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DATA  BASE 


MODULE 


MODULE  TO  DATA  BASE 
FLOW 


MODULE  TO  MODULE 
FLOW 


B-l  Information  Flow 


criteria  to  be  considered  are  the  scope-of-effect  and  the 
scope-of-control . Scope-of-effect  is  the  collection  of  all 
modules  cjntaining  any  processing  that  is  conditional  upon 
a particular  decision.  Scope-of-control  is  a module  and  all 
of  its  subordinates.  The  objective  is  to  have  the  scope-of- 
effect  and  the  scope-of-control  coincide. 


Structured  Chart  Syntax 


Structured  charts  consist  of  modules  connected  either 
to  modules  and/or  to  data  bases  by  information  flow  lines  or 
by  connection  lines.  Figure  B-l  illustrates  the  basic  syn- 
tax for  connecting  modules  and  data  bases.  The  solid  line 
represents  a normal  connection.  A dashed  line  represents  a 
transfer  of  control  irhlch  takes  place  automatically, 


B-2  Information  Arrow  Types 


asynchronously  or  concurrent- 
ly with  established  proces- 
ses. This  includes  program  • . . 

interrupts  and  parallel  sub- 
routine calls.  CNote  that 

the  data  base  is  designated  ^ ® 

DATA  CONTROL  DATA  AND 
by  a rectangle  with  curved  CONTROL 

sides.)  Connections  are  ~ ~~  ~~  — — • • 

ordered  1 eft-to-rlght  as  B-2  Information  Arrow  Types 

they  emerge  from  the  re- 
ferencing moduel  in  the  same  order  that  they  would  usually 
be  accessed.  The  arrows  adjacent  to  any  connection  Indi- 
cate the  direction  of  the  flow  of  information. 

The  three  types  of  arrows  used  are  Illustrated  in 
Figure  B-2.  An  arrow  with  a small  circle  on  its  tail  always 
denotes  data.  An  arrow  with  a dot  (point)  on  its  tail  al- 
ways denotes  control.  A plain  arrow  denotes  either  control, 
data  or  both. 

Conditional  access  to  intermodular  connection  is  shown 
by  enclosing  the  point(s)  of  reference  in  a diamond  (decision 
symbol)  as  illustrated  In  Figure  B-3.  When  intermodular 
references  are  used  repeatedly  within  an  Iterative  procedure 
(loop),  the  beginnings  of  the  connection(s)  are  encompassed 
by  a half  loop  as  shown  In  Figure  B-3. 


SYSTEM 


Figure  C-2  SYSTEM  Record 


MANUFACTURERS 


MODULE-REV 


Figure  C - 1 4 DOC-TYPE  Record 


Figure  C-17  DOC-CONFIG  Record 


Figure  C-20  ECP-REV  Record 


Figure  C-23  ECP-REV/DOC-CONFIG  Record 
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Table  C-I 

Data 

Item  Definitions 

Data  Item 

Description 

CBLI  Serial  Number 

Line  Item  number  on  a contract 

CDR  Date 

Date  critical  design  review  accom- 
pl  Ished 

Classification  Code 

Manufacturer's  code  to  Identify 
class  of  functions  performed  by 
program  modules 

Classification  ID 

Data  aggregate  that  Identifies  a 
specific  class  of  module  functions 
for  an  organization 

Classification  Name 

Name  for  a classification  Identifier 

CPCI  Distribution  Date 

Date  a revision  to  a CPCI  Is  dis- 
tributed 

i r 

CPCI  Name 

Name  of  a CPCI 

CPCI  Rev  ID 

Data  aggregate  that  Identifies  a 

specific  revision  to  a CPCI 

CPCI  Revision  Code 

Code  to  Identify  revisions  to  CPCI 

CPDP  Date 

Date  computer  program  development 
plan  was  distributed 

CPDP  Number 

Unique  number  assigned  to  a computer 
program  development  plan 

CPIN 

Unique  number  assigned  to  a computer 
program  configuration  Item 

CN  Date 

Date  of  delivery  of  a change  notice 

CN  Priority 

Code  that  Identifies  the  priority 
assigned  to  delivering  a change 
notice 

CN  Serial  Number 

Sequence  number  assigned  to  a change 

% 
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CRISP  Date 


CRISP  Number 


DOC  Base  Number 


Distribution  date  of  computer  re- 
sources Integrated  support  plan 

Unique  number  assigned  to  a com- 
puter resource  Integrated  support 
pi  an 

Unique  number  assigned  to  a docu- 
ment or  set  of  related  documents 


DOC  Conflg  ID  Data  aggregate  that  uniquely 

.Identifies  the  configuration  of  a 
specific  CPCI  support  document 

DOC  Distribution  Date  Distribution  date  of  a revision  to 

a maintainable  document 


DOC  Due  Date 


Due  date  of  a revision  to  a main 
talnable  document 


DOC  ID 


DOC  Priority 


DOC  Remarks 


Data  aggregate  that  uniquely  Ident- 
Identlfies  a maintainable  document 
(part  of  an  item's  configuration 
Identification) 

Code  that  Identifies  the  priority 
assigned  to  distributing  a document 

Narrative  for  a revision  of  a docu- 
ment 


DOC  Rev  Change  Level 


DOC  Rev  ID 


DOC  Revision  Level 


DOC  Title 


DOC  Type  Code 


DOC  Type  Name 
DOC  Volume  Number 


Code  that  identifies  the  number  of 
change  notices  Issued  against  a re- 
vision of  a document 

Data  aggregate  that  uniquely 
identifies  a revision  to  a specific 
maintainable  document 

Code  that  Identifies  the  last  re- 
vision of  a document  that  was  Issued 

Title  assigned  to  a specific  docu- 
ment or  set  of  documents 

Code  that  uniquely  Identifies  a 
type  (class)  of  documents 

Name  of  a type  of  document 

Identifier  of  a volume  of  a document 
(Note:  The  volumes  of  a document  are 
treated  as  Individual  members  of  a 
set  of  documents) 


ECP  Base  ID  Data  aggregate  that  uniquely  Identl 

ftes  a group  of  related  ECPs  for  a 
specific  system 

ECP  Base  Number  Identifier  of  a group  of  related 

ECPs 

ECP  Change  Incorp  Organizational  level  Incorporating 

Level  the  change 

ECP  Change  Level  Code  that  Identifies  the  number  of 

times  an  ECP  has  been  revised 

ECP  Class  Number  that  Identifies  the  change 

class  to  which  the  ECP  has  been 
assigned:  I or  II 

ECP  Description  Brief  narrative  Identifying  why 

the  change  Is  required 

ECP  ID  Data  aggregate  that  uniquely  Identl 

fles  a proposed  change  to  a CPCI 
or  Cl 

ECP  Justification  Code  Code  that  Identifies  the  reason  for 

a proposed  change 

ECP  Milestone  Actual  Date  that  an  ECP  milestone  was 

reached 

ECP  Milestone  Comment  Brief  narrative  associated  with  an 

ECP  milestone 

ECP  Milestone  Name  Name  of  a milestone  for  an  ECP 


ECP  Milestone  Sched 


Date  by  which  an  ECP  milestone 
should  be  reached 


Code  that  Identifies  the  priority 
of  an  ECP 


ECP  Relational  Number 


Number  that  Is  used  to  distinguish 
between  members  of  a group  of  re- 
lated  ECPs 


ECP  Remarks 


Narrative  associated  with  a unique 
ECP  revision 

Code  that  Identifies  a revision  to 
an  ECP 


ECP  Rev  ID 


Data  aggregate  that  uniquely  Identi- 
fies an  ECP  revision 


i 
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ECP  Solution 

ECP  Status 

ECP  Title 
ECP  Type 

FCA  Date 

Fiscal  Year 
FQR  Date 

Function  Code 

Function  ID 

Function  Name 


Narrative  describing  a proposed 
change 

Code  that  Identifies  the  current 
status  of  an  ECP 

Title  of  an  ECP 

Code  that  Identifies  an  ECP  as  pre- 
1 Imlnary  or  formal 

Date  that  the  functional  configura- 
tion audit  was  accomplished 

Number  that  Identifies  a fiscal  year 

Date  that  the  formal  qualification 
review  was  accomplished 

Manufacturer  supplied  code  to 
Identify  a function  performed  by  a 
CPCI  module 

Data  aggregate  that  uniquely  Identi- 
fies a function  performed  by  a group 
of  modules  supporting  a specific 
CPCI 

Name  assigned  to  a function  Identi- 
fier 


Item  Identification  Code  that  uniquely  Identifies  a 

status  accounting  data  Item 

Item  Type  Code  that  Identifies  a status 

accounting  data  Item  type 


Language 


Code  for  the  programming  language 
In  which  a module  Is  written 


Manufacturer  Addr 


Manufacturer  Code 


Manufacturer  Name 


The  address  of  a computer  resource 
supplier 

Code  that  uniquely  Identifies  a 
Government  supplier 

Name  of  a Government  supplier 


|| 
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Milestone  Code 


Code  that  uniquely  Identifies  a 
milestone 


Milestone  Name  Name  assigned  to  a particular 

milestone 

Module  Code  Manufacturer  supplied  code  to 

Identify  a program  module 

Module  Description  Brief  description  of  the  purpose  of 

a program  module 

Module  ID  Data  aggregate  that  uniquely  Identi- 

fies a program  module  being  acquired 
by  a program  office 

Module  Name  Name  assigned  to  a program  module 

Module  Rev  ID  Data  aggregate  that  uniquely  Identi- 

fies a revision  to  a CPCI  program 
module 

Module  Rev  Code  Code  that  Identifies  a revision  to 

a program  module 

Module  Rev  Date  Date  that  a revision  to  a program 

module  was  distributed 

Module  Revision  Code  that  identifies  the  priority 

Priority  assigned  to  delivering  a revision 

to  a program  module 

Module  Rev  Remarks  Narrative  for  comments  about  a pro- 

gram module  revision 

Object  Length  The  number  of  bytes  required  to  store 

a program  module  in  object  form 

Object  Media  Address  Logical  storage  device  addr  of  a 

program  module  a In  object  form 

Object  Media  Number  Identifier  of  a storage  device  con- 

taining a program  module  In  object 
form 

Object  Media  Type  Type  of  storage  media  containing  a 

program  module  In  object  form 

Operating  Mode  Code  Manufacturer  supplied  code  to 

Identify  an  operating  mode  in  which 
a CPCI  can  execute 
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Op  Mode  ID 

Organization  Address 
Organization  Code 

Organization  Name 
0/S  CMP  Date 

O/S  CMP  Number 

PCA  Date 
PMD  Date 


Data  aggregate  that  uniquely  Identi- 
fies an  operating  mode  for  each  of 
an  organization's  CPCIs 

Address  of  a Government  organiza- 
tion procuring  a system 

Code  that  uniquely  Identifies  a 
Government  organization  procuring  a 
system 

Name  of  a Government  organization 
procuring  a system 

Date  operatlonal/support  configura- 
tion management  procedures  were 
distributed  for  a system  being 
acquired 

Unique  number  assigned  to  an  opera- 
tlonal/support conflg  mgmt  proce- 
dures document 

Date  physical  configuration  audit 
accompl 1 shed 

Date  program  management  directive 
was  distributed 


PMD  Number 


PMP  Date 


Unique  number  assigned  to  a program 
management  directive 

Date  program  management  plan  was 
distributed 


PMP  Number 


Unique  number  assigned  to  program 
management  plan 


Procurement  Instru-  Sequential  number  assigned  to  a 

ment  Serial  Number  Government  procurement  Instrument 


Procurement  Instrument  Type  of  agreement  between  the 
Type  Government  and  the  supplier 


SDR  Date 


Date  system  design  review  accom- 
plished 


Source  Length 


Number  of  bytes  needed  to  store  a 
program  module  In  source  form 


Source  Media  Addr  Logical  storage  device  addr  of  a pro 

gram  module  In  source  form 
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Source  Media  Number 


Source  Media  Type 


SRR  Date 


Sub-cl ass  1 f Icatlon 
code 


Sub-classification  ID 


Sub-classification 

Name 

System  Code 


System  ID 


System  Name 


Identifier  of  a storage  device  con- 
taining a program  module  In  source 
form 

Type  of  storage  media  containing 
a program  module  In  source  form 

Date  system  requirements  review 
accomplished 

Manufacturer  supplied  code  to 
Identify  a sub-class  of  functions 
performed  by  a program  module 

Data  aggregate  that  Identifies  a 
specific  sub-class  of  module 
functions  for  an  organization 

Name  for  a sub-classification 
Identl f ler 

Code  that  Identifies  an  acquisition 
program  for  computer  resources 

Data  aggregate  that  uniquely  Identi- 
fies a system  being  acquired 

Name  for  a system  being  acquired 
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